Open caenrique opened 4 months ago
tgodzik
commented
4 months ago Thanks for reporting! What kind of error show up? Have you been using Bloop in the past, or is there a .bloop directory (that looks to cause the last error). There rest of the errors don't seem to have a lot to do with your issues, might be transient related to a non compiling code during some changes
tgodzik
commented
4 months ago Also, are you using Java language server aside from metals?
caenrique
commented
4 months ago Hi @tgodzik !
What kind of error show up?
the main thing is that I get lots of compilation errors in the metals log, while sbt on its own compiles just fine. The result is that some things like type hints and go to definition doesn't work (this one in particular for classes defined in java dependencies).
I am using smithy4s-sbt-codegen which generates code in a sub-module, and then the rest of modules depend on this one. My intuition is that there is something cached somewhere that metals is not updating and using an older version of the code, because the compilation errors are signature changes like:
2024.07.03 14:02:13 ERROR -- [E007] Type Mismatch Error: ***.scala:41:43
41 | preferredImage = choosePreferredVariant(catalogImageVariants),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| Found: playback.Image
| Required: Option[playback.Image]If I delete all the folders related to metals (.metals, .bloop, .bsp) and import the project, bloop is started as the default, but I switch to sbt since until now it has been working better in my own experience. I'm not aware if there is a new setting to use sbt by default?
Also, are you using Java language server aside from metals?
No
tgodzik
commented
4 months ago If I delete all the folders related to metals (.metals, .bloop, .bsp) and import the project, bloop is started as the default, but I switch to sbt since until now it has been working better in my own experience. I'm not aware if there is a new setting to use sbt by default?
There is actually a setting for that, it's metals.defaultBspToBuildTool
So those errors happen after changes to the generated sources? If you clean compile it works correctly? If you're using sbt BSP it should really show all the same errors as sbt does, so this is highly confusing, since those errors are actually produced by sbt
caenrique
commented
4 months ago yes, both sbt "clean; compile" and even just sbt compile in the root of the project work just fine without any errors
tgodzik
commented
4 months ago I am a bit lost then, are you able to set up a small reproduction? Or at least sent the full .metals/metals.log file?
caenrique
commented
4 months ago I'm not sure what the issue was, but after deleting everything that I could find related to metals or bloop seem to have solved the inconsistency between metals and sbt. It is a huge project and I don't know the root cause of the issue, so I don't think I can create a small reproduction.
caenrique
commented
4 months ago The java go to definition however is still not working as expected. I've noticed that for some dependencies it works correctly, but for others it doesn't. Enabling the lsp tracing shows that the textDocument/definition lsp call returns an empty results array sometimes. Do you know why this could be or how can I investigate it further?
tgodzik
commented
4 months ago That depends, if we don't have any sources for those dependencies then indeed we will not find the definition, though we download them automatically usually, so this would probably only be an issue for local built jars.
The other options is missing semanticdb or non compiling code, but this might really be a very specific issue with that dependency that we haven't thought about.
Describe the bug
Compilation fails on my project with logs showing a bunch of compilation errors, however using sbt directly compiles just fine. Go to definition doesn't work for java sources
doctor output (redacted paths):
Metals Info
Below are listed the build targets for this workspace. One build target corresponds to one classpath. For example, normally one sbt project maps to two build targets: main and test.
Workspaces
Workspace: ***
Build Targets
root
root-test
integrationTests
integrationTests-test
playback
playback-test
root-build
smithyModels
smithyModels-test
Error Reports
compiler-error
Summary
java.lang.AssertionError: NoDenotation.owner
compiler-error
Summary
java.lang.AssertionError: NoDenotation.owner
Empty build targets....
Summary
Empty build targets. Expected at least one build target identifier.
Expected behavior
Operating system
macOS
Editor/Extension
Nvim (nvim-metals)
Version of Metals
v1.3.2
Extra context or search terms
No response