Build target not found and compilation fails

[caenrique]

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

• Metals Server version: 1.3.2
• Metals Java: 21.0.3 from Amazon.com Inc. located at ***

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 server currently being used is sbt v1.10.0.

Build Targets

root

• target type: Scala 3.3.3
• goto functionality: metalsDecode:file:///***
• compilation: ✅
• diagnostics: ✅
• interactive: ✅
• semanticdb: ⚠️
• debugging: ✅
• java: ⚠️

root-test

• target type: Scala 3.3.3
• goto functionality: metalsDecode:file:///***
• compilation: ✅
• diagnostics: ✅
• interactive: ✅
• semanticdb: ⚠️
• debugging: ✅
• java: ⚠️

integrationTests

• target type: Scala 3.3.3
• goto functionality: metalsDecode:file:///***
• compilation: ✅
• diagnostics: ✅
• interactive: ✅
• semanticdb: ⚠️
• debugging: ✅
• java: ⚠️

integrationTests-test

• target type: Scala 3.3.3
• goto functionality: metalsDecode:file:///***
• compilation: ✅
• diagnostics: ✅
• interactive: ✅
• semanticdb: ⚠️
• debugging: ✅
• java: ⚠️

playback

• target type: Scala 3.3.3
• goto functionality: metalsDecode:file:///***
• compilation: ❌
• diagnostics: ✅
• interactive: ✅
• semanticdb: ✅
• debugging: ✅
• java: ⚠️

playback-test

• target type: Scala 3.3.3
• goto functionality: metalsDecode:file:///***
• compilation: ✅
• diagnostics: ✅
• interactive: ✅
• semanticdb: ⚠️
• debugging: ✅
• java: ⚠️

root-build

• target type: sbt 1.10.0
• goto functionality: metalsDecode:file:///***
• compilation: ✅
• diagnostics: ✅
• interactive: ✅
• semanticdb: ✅
• debugging: ❌
• java: ⚠️
• recommendation: Diagnostics and debugging for sbt are not supported currently.

smithyModels

• target type: Scala 3.3.3
• goto functionality: metalsDecode:file:///***
• compilation: ✅
• diagnostics: ✅
• interactive: ✅
• semanticdb: ✅
• debugging: ✅
• java: ⚠️

smithyModels-test

• target type: Scala 3.3.3
• goto functionality: metalsDecode:file:///***
• compilation: ✅
• diagnostics: ✅
• interactive: ✅
• semanticdb: ⚠️
• debugging: ✅
• java: ⚠️

Error Reports

compiler-error

• timestamp: 1720007476558
• uri: file:///***/.metals/.reports/metals-full/2024-07-03/r_compiler-error_13-51-16-558.md
• error type: metals-full

Summary

java.lang.AssertionError: NoDenotation.owner

compiler-error

• timestamp: 1720007475300
• uri: file:///***/.metals/.reports/metals-full/2024-07-03/r_compiler-error_13-51-15-300.md
• error type: metals-full

Summary

java.lang.AssertionError: NoDenotation.owner

Empty build targets....

• timestamp: 1720007449629
• uri: file:///***/.metals/.reports/bloop/2024-07-03/r_Empty%20build%20targets...._13-50-49-629.md
• error type: bloop

Summary

Empty build targets. Expected at least one build target identifier.

Expected behavior

• compilation should be successful
• go to functionality should work for java sources

Operating system

macOS

Editor/Extension

Nvim (nvim-metals)

Version of Metals

v1.3.2

Extra context or search terms

No response

[tgodzik]

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]

Also, are you using Java language server aside from metals?

[caenrique]

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]

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]

yes, both sbt "clean; compile" and even just sbt compile in the root of the project work just fine without any errors

[tgodzik]

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]

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]

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]

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.