Fix copying tasty files on incremental compilation #1701
Conversation
Previously, we removed both generatedClassFile and rebasedClassFile from invalidations, but we only did it for rebased product files such as `.tasty`. Now we do it for both I am not 100% sure why sometimes invalidations happen for rebased and sometimes for generated files, but that can happen according to the comment above. What happened here is that the generated files existed, but the rebased one was in the invalidation list, so later on we would skip it.
|
Question for Zinc newbies, what are |
I think the rebased one is the on where we put copy of files for the client. |
|
Actually, now I think of it. Rebased might be a new directory and we might always be compiling to a new directory but using the artifacts from the old one. 🤔 |
|
@tgodzik ELI5: what is this PR about and what are invalidations. 🙏 Incremental compilation isn't my strong side yet :D |
Ach sorry, each time anything changes in the code the files get invalidated (meaning they need recompilation) and when those get recompiled we might need to recompile some additional files etc. |
|
I will go ahead and merge this since from my understanding this is the safest choice. I think the main reason for this is that we change output directory on each compilation, which is why there might be different paths for invalidated files and new generated ones. |
Previously, we removed both generatedClassFile and rebasedClassFile from invalidations, but we only did it for rebased product files such as
.tasty. Now we do it for bothI am not 100% sure why sometimes invalidations happen for rebased and sometimes for generated files, but that can happen according to the comment above.
What happened here is that the generated files existed, but the rebased one was in the invalidation list, so later on we would skip it.
This was causing the issues in scalameta/metals#3706