fix: check if products were removed in inc compilation #1772
Conversation
Do it in the same way how it's implemeted in zinc - https://github.com/sbt/zinc/blob/189d33bcf6678fcc86e7e3e438c551d6cc51be8a/internal/zinc-core/src/main/scala/sbt/internal/inc/IncrementalCommon.scala#L396-L405 Technically it shouldn't be an issue, if user don't touch clasees then there is no need to check `removedProducts`. However, sometimes when I do a lot of switches between branches in combination with Metals by some reason I'm getting an invalid state of project where some products were removed and their sources aren't presented in changed files.
There was a problem hiding this comment.
What kind of issues do you get? Bloop compiles things to a separate readonly directory and then it copies over the results (at least I think this is the intention). So no unused files should show up. Maybe it's an issue that we don't recompile when removing files?
|
@tgodzik The situation is exactly as it described in a test that I added with an only difference that class files just don't exists while the current analysis doesn't know about that. Unfortunately, I haven't found a reliable way to reproduce it. I guess maybe Metals might trigger compilation in a half way of checkout (git performs a file rewrite as delete + write a fresh one) or it somehow related to sbt/zinc#683 or #980 |
Do it in the same way how it's implemeted in zinc - https://github.com/sbt/zinc/blob/189d33bcf6678fcc86e7e3e438c551d6cc51be8a/internal/zinc-core/src/main/scala/sbt/internal/inc/IncrementalCommon.scala#L396-L405
Technically it shouldn't be an issue, if user don't touch clasees then
there is no need to check
removedProducts.However, sometimes when I do a lot of switches between branches in
combination with Metals by some reason I'm getting an invalid state of project where some products were
removed and their sources aren't presented in changed files.