Errors aren't being reported on scala-cli scripts runs

[anatoliykmetyuk]

Describe the bug

When I use the "run" functionality of Metals in VS Code to run a scala-cli script with error, it doesn't show any error but silently re-runs the last version of the script it was able to compile successfully.

Screen.Recording.2023-11-08.at.14.50.22.mov

Expected behavior

Should emit an error instead of re-running the last successful compilation result.

Operating system

Windows

Editor/Extension

VS Code

Version of Metals

v1.1.0

Extra context or search terms

No response

[tgodzik]

Thanks for reporting! The issue here is that this is all handled on the VS Code side to make it faster. We could possibly invoke compile first and check for errors, but that might be much slower. Anyway we might need to do that at some point.

[bishabosha]

Vs code reports problems in the workspace (aka compile errors) could these be tracked to prevent run? (As long as they are actual compile errors and not those scalameta/bloop errors that are inaccurate)

[tgodzik]

That's one option, yeah. Would need to be fixed in vs code plugin itself.

[kasiaMarek]

I don't think it's achievable to do it in the client. There might be errors in other build targets (e.g. tests) which are unrelated, the client wouldn't be able to tell which files belong to which build target.

We could simply not show run/debug code lenses when the code doesn't compile.

[tgodzik]

We would need to run refresh code lense on error, which would make these disappear. We could also make VS Code run save before running anything and that should wait for the compilation.

[tgodzik]

Just checked and it seems just running save is not enough, we would need a Compile command and it should wait for the actual compilation to finish (not sure if not for main class request also)

[anatoliykmetyuk]

We could simply not show run/debug code lenses when the code doesn't compile.

I would say that hinders user experience. I have this experience with Metals: when I open a Scala file, and the code lenses sometimes show up and sometimes don't. That creates a perception of them being flaky and unreliable, as when they don't show up, you have no idea what you did wrong and how to get them back.

If something doesn't work as expected, the user should get clear feedback from the program in the form of an error message, otherwise, it's hard to debug unless you already have experience with the setup.

This stands in contrast with Python's approach - they just use the "Run" button built-into editor, it's always there and is perceived as stable.

[tgodzik]

Code lenses depend on semanticdb, we might need to rethink that or try to improve semanticdb support, since it's very easily breakable.

But apart from code lenses, you can always just use the built in run functionality, it will run anything from the current file. Adding and additional button would be redundant in that case.