Best effort compilation gives false errors

[brndt]

Describe the bug

If I make any changes in the code and break compilation, the compiler gives random totally non-related errors.

For example:

be_test.mov

Expected behavior

No response

Operating system

macOS

Editor/Extension

VS Code

Version of Metals

1.3.4

Extra context or search terms

No response

[tgodzik]

Thanks for reporting! I wonder if this might be connected to the fact that we now compile all modules and sometimes this might lead to worse errors in the dependent modules.

Best effort itself will not produce any new diagnostics.

[filipwiech]

I can confirm the same behaviour in my project. 👍

In fact, it also appears that even if I make the code compile successfully again (as confirmed by the SBT build), but not by reverting the file to the initial state (e.g. with undo), but by further modifying the implementation to fix it, then the bogus error diagnostics are still visible. 🤔

To add additional data point: I just had a case where I got weird (and incorrect) error diagnostics shown in the edited file (some imported types suddenly cannot be found), even though my changes did compile successfully from the get go, build was not broken at any point, I have only removed an unused implicit definition (although I did get an unused import warning from the compiler in the SBT afterwards if that matters, albeit I have no -Werror enabled, so the build was fine still). 😮 Had also a similar scenario after removing unused import from a completely different file (sudden errors about missing unrelated types).

Scala 3.5.0-RC6, Bloop 1.6.0, SBT 1.10.1, Metals 1.3.4+23-c744a47f-SNAPSHOT

[filipwiech]

One more update (sorry for a lot of messages, but I hope it will be useful info for you): while usually SBT build gives expected results (either a successful compilation or an error that is real and makes sense), I have regularly observed that after a while (of Metals compiling the project due to the editor changes) SBT seems to deteriorate as well and starts spewing weird messages (cannot find imports/types, broken build). After a clean build it starts working again and is good for some time. 🙁

At this point Metals is almost unusable for me with a Scala 3.5 project. @tgodzik Is there any way to disable the Best Effort Compilation for the time being? 😕

[tgodzik]

We might have to add a setting for that if it turns out to be the problem, but I can't imagine why would this happen.

I will check it out today.

[tgodzik]

I will have to disable it, thanks for catching this before the actual release of 3.5.0! I will have to do a new release with this probably tomorrow.

@jchyb is on vacation till 16th, and I think I will have to ask him to take a look again. @brndt is it ok if I share your codebase with him once he's available?

[brndt]

I will have to disable it, thanks for catching this before the actual release of 3.5.0! I will have to do a new release with this probably tomorrow.

@jchyb is on vacation till 16th, and I think I will have to ask him to take a look again. @brndt is it ok if I share your codebase with him once he's available?

Yes of course.

[gchudnov]

wondering if there is any update?

with the release of 3.5 tried to enable best effort compiling on Metals version: 1.3.5+68-5948c4fe-SNAPSHOT by enabling -Dmetals.enable-best-effort=true, but looks like bumped into a similar issue, so disabled it... (to be honest not sure if the issue is actually metals or scala related)

[jchyb]

Still working on this. It looks like the issue is moreso on the build server side, so the best effort compilation should still work on 3.5 once we fix this issue.

[filipwiech]

@jchyb Thank you for looking into this. 👍 Just in case, a related issue #6627 caused by the Best Effort compilation was closed earlier, but that one seems to be somewhat distinct, as it impacts macros specifically (seemingly in the test scope only), even in a completely clean project build with no other errors. I have no idea if the root cause is the same, but wanted to highlight it, as it might have got lost in the meantime. 🙂

[bloznelis]

Can confirm that this issue persists in metals 1.3.5 with Scala 3.5.0 when enabling best effort compilation with -Dmetals.enable-best-effort=true.

From what I gathered, there's only one type of error—"value foo is not a member of bar"—and is triggered only for the imports. Hope this helps to track it down.

[tgodzik]

One issue still existing (not sure if caused by best effort) :

• changing a name of a class isn't picked up in downstream projects

[tgodzik]

My guess is that we don't remove early compilation in the client dir, but not sure if that is the only issue.

[bloznelis]

To be honest, I cannot reproduce this issue anymore with:

• Metals 1.4.0
• Scala 3.5.2
• Bloop 2.0.3

[jchyb]

The main issue reported here got fixed in bloop v2.0.4. Depending on the dependency graph between files, and which files we recompile, it might not even show in earlier versions, even when -Dmetals.enable-best-effort=true is used (which is how we missed it before). Looks like @tgodzik found an additional problem that we will be fixing shortly

[brndt]

Copy paste from discord canal:

I've tried to use best effort compilation with the latest version of Bloop and it's unusable :( - having a lot of random and out of sync errors. For example, removing class that's used by the others is no longer detected by the compiler, a vice-versa, like you can see on the screenshot.

and here it can't even detect 'succeed' method of ZIO