Goto definition doesn't work for java records

[ghostbuster91]

Describe the bug

Goto definition doesn't work for java records.

Example project here: https://github.com/ghostbuster91/demos/tree/goto-records

Open project, go to Main.scala file and observe following:

package hello

object Main {

  def main(args: Array[String]) = {
    println(new ScalaRecord(new BRecord(new SRecord("")), new Regular()))
                // ^ goto-works    ^doesn't    ^doesn't         ^goto-works
  }
}

It also doesn't work between the record classes, and when trying to go from regular java class to a record class.

Expected behavior

I would expect go-to definition to work in all cases and navigate to java record classes.

Operating system

Linux

Editor/Extension

Nvim (nvim-metals)

Version of Metals

1.0.1

Extra context or search terms

Interesting enough if you call find references on a java record usage it will show all references including the definition.

records, java

[tgodzik]

Thanks for reporting! I am pretty sure that we haven't tested that ever, might be related to the java semanticdb plugin :thinking:

[kasiaMarek]

JavaMtags do not index records. I think an upstream fix in https://github.com/paul-hammant/qdox might be needed. It seems they don't fail when parsing records but don't really support them.

might be related to the java semanticdb plugin

That part is fine, thus the references working.

[hmf]

Is this just for records? I am having trouble with standard methods. The issue #2493 seem to suggest it should be working, but I started the bloop server automatically (no additional command line parameters). Using Mill.

Don't know the exact version. It shows v1.25.0 but I accept snapshots. Info states updated on the 2023-10-10, 13:36:21

[tgodzik]

Is this just for records? I am having trouble with standard methods. The issue #2493 seem to suggest it should be working, but I started the bloop server automatically (no additional command line parameters). Using Mill.

Don't know the exact version. It shows v1.25.0 but I accept snapshots. Info states updated on the 2023-10-10, 13:36:21

The issue might be that the semanticdb was not generated for the file :thinking: Do you see anything in the logs?

[hmf]

@tgodzik

I see nothing suspicious. Here is what I have:

2023.10.16 08:26:20 INFO  Started: Metals version 1.0.1+109-63a65d29-SNAPSHOT in folders '/workspaces/storch' for client Visual Studio Code 1.83.1.
2023.10.16 08:26:21 INFO  Attempting to connect to the build server...
2023.10.16 08:26:21 INFO  Bloop uses /usr/local/sdkman/candidates/java/current defined at /home/vscode/.bloop/bloop.json
2023.10.16 08:26:21 INFO  skipping build import with status 'Installed'
2023.10.16 08:26:21 INFO  tracing is disabled for protocol BSP, to enable tracing of incoming and outgoing JSON messages create an empty file at /workspaces/storch/.metals/bsp.trace.json or /home/vscode/.cache/metals/bsp.trace.json
2023.10.16 08:26:21 INFO  time: Connected to build server in 0.26s
2023.10.16 08:26:21 INFO  Connected to Build server: Bloop v1.5.11
Oct 16, 2023 8:26:24 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 2
2023.10.16 08:26:26 INFO  time: indexed workspace in 4.81s
2023.10.16 08:26:31 WARN  Using indexes to guess the definition of orthogonal_
2023.10.16 08:26:38 WARN  Using indexes to guess the definition of orthogonal_
2023.10.16 08:26:39 WARN  Using indexes to guess the definition of orthogonal_

Those last 3 messages occur when I try to do to the definition of the torchNative.orthogonal_ call below (one click seems to produce 2 of those messages).

  def orthogonal_(
      t: Tensor[?],
      gain: Double = 1.0
  ): Unit =
    torchNative.orthogonal_(t.native, gain)

I have just realized that the IDE then places me on the Scala line of the orthogonal_ method. When I hover over the Java call, I get def orthogonal_(x$0: Tensor, x$1: Double): Tensor. Hovering over torchNativethe IDE correctly shows me object torch: org.bytedeco.pytorch.global. The actual API is found here

A clean and restart of the builder does not seem to help. Log shown below.

2023.10.16 08:38:30 INFO  Disconnecting from Bloop session...
2023.10.16 08:38:30 INFO  Shut down connection with build server.
2023.10.16 08:38:30 INFO  Deleted directories inside .bloop
2023.10.16 08:38:30 INFO  Attempting to connect to the build server...
2023.10.16 08:38:30 INFO  Bloop uses /usr/local/sdkman/candidates/java/current defined at /home/vscode/.bloop/bloop.json
2023.10.16 08:38:31 INFO  tracing is disabled for protocol BSP, to enable tracing of incoming and outgoing JSON messages create an empty file at /workspaces/storch/.metals/bsp.trace.json or /home/vscode/.cache/metals/bsp.trace.json
2023.10.16 08:38:31 INFO  time: Connected to build server in 1.43s
2023.10.16 08:38:31 INFO  Connected to Build server: Bloop v1.5.11
2023.10.16 08:38:32 INFO  time: Imported build in 0.19s
2023.10.16 08:38:33 INFO  time: indexed workspace in 0.97s
2023.10.16 08:38:34 INFO  compiling core (63 scala sources)
2023.10.16 08:38:43 INFO  compiling core.test (22 scala sources)
2023.10.16 08:38:43 INFO  compiling vision (4 scala sources)
2023.10.16 08:38:43 INFO  time: compiled core in 9.5s
2023.10.16 08:38:44 INFO  compiling vision.test (1 scala source)
2023.10.16 08:38:44 INFO  compiling examples (8 scala sources)
2023.10.16 08:38:44 INFO  time: compiled vision in 1.11s
2023.10.16 08:38:44 INFO  time: compiled vision.test in 0.35s
2023.10.16 08:38:49 WARN  there were 8 deprecation warnings; re-run with -deprecation for details
2023.10.16 08:38:49 INFO  time: compiled examples in 4.84s
2023.10.16 08:38:49 INFO  time: compiled core.test in 6.77s
2023.10.16 08:39:44 WARN  Using indexes to guess the definition of orthogonal_

[hmf]

@tgodzik small update. Latest snapshot has the same issue above. But I can confirm that with Java methods with different name, got-to works well.

[tgodzik]

Would you be able to provide a small reproduction? It seems to work correctly for me if I define a method ending with _ both in Java and Scala

[hmf]

Will try.

[kasiaMarek]

Upstream fix: https://github.com/paul-hammant/qdox/pull/191