metals-vscode: Wrongly provides Go to definition results to java project

Describe the bug

The Metals Scala extension is used in “Go to definition” in a java project, which leads to not showing the actual definition used in e.g., a call of a method but all methods that match the name inside the project.

To Reproduce Steps to reproduce the behavior:

  1. Install Java language server extension (redhat)
  2. Install Metals Extension
  3. Create java project
  4. Create java class
class GoToDefinitionTest {
  public String method1(String param) {
    return method1(param, null); // Ctrl+Click on method1 here
  }

  public String method1(String param, String otherParam) {
    return method1(param, otherParam, null);
  }

  public String method1(String param, String otherParam, String yetAnotherParam) {
    return "Hello";
  }
}
  1. Ctrl+click or use Go to definition from the context menu on the method1 call indicated via source comment
  2. see definitions provided by metals rather than java extension (see screenshots below)

Expected behavior

The java language server extension provides the information for “Go to Definition” for the java project.

Screenshots

Here you can see the definition info provided apparently by the metals extension (see next screenshot for metals log) image

Here you can see metals provides the information for method1 Go to image

Installation:

  • Operating system: Windows UI, Remote SSH Linux
  • VSCode version: 1.78.1
  • VSCode extension version: v1.23.0
  • Metals version: 0.11.12

Additional context

see reported issue in the java extension for vscode https://github.com/redhat-developer/vscode-java/issues/3095

also if I downgrade to v1.21.0 of the metals extension it seems to work as expected.

Search terms

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 1
  • Comments: 15 (9 by maintainers)

Most upvoted comments

@tanishiking suggested that we can us perhaps https://stackoverflow.com/questions/73059687/how-to-obtain-a-list-of-installed-vs-code-extensions-using-code to check if Redhat plugin is active

on the other hand (since not sure if we can check if it’s active) @dos65 suggested:

There is vscode.ExtensionContext.globalState.setKeyForSync 
In theory, we can try to exchange data over it between redhat and metals to show warnings that you have to disable one of plugins