Signature help shows wrong active parameter for methods with type params and empty param list.

[rochala]

Compiler version

3.4.1

Minimized code

  // file dotty/tools/pc/tests/signaturehelp/SignatureHelpSuite.scala
  @Test def `proper-param-empty-list` =
    check(
      """
        |object x {
        |  def foo[K, V](): Unit = ???
        |  foo(@@)
        |}
        |""".stripMargin,
      "foo[K, V](): Unit"
    )

Output

Last parameter is selected as current argument.

Expectation

No element should be selected as active parameter.

[mbovel]

This issue was picked for the Scala Issue Spree of tomorrow, April 9th. @rochala, @mbovel, @iusildra, @nmcb will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

[mbovel]

Rust-analyzer behavior for comparison, it shows an index higher than the maximum parameter index:

Result: {
    "signatures": [
        {
            "label": "fn foo(_x: i32)",
            "parameters": [
                {
                    "label": [
                        7,
                        14
                    ]
                }
            ],
            "activeParameter": 1
        }
    ],
    "activeSignature": 0,
    "activeParameter": 1
}

Where src/bin/hello.rst is:

fn foo<T>(_x: i32) {
}

fn main() {
    foo::<i32>(32, **CURSOR_HERE**);
    println!("Hello, world!");
}

And cargo.toml is:

[workspace]

[package]
name = "hello" # the name of the package
version = "0.1.0"    # the current version, obeying semver
authors = ["Alice <a@example.com>", "Bob <b@example.com>"]

[[bin]]
name = "hello"

Screenshots:

[mbovel]

For context and for the record, we observed during the spree that the language server protocol currently does not provide a way to indicate that no parameter is active. Instead, the specification says that any parameter outside of the range will default to 0:

        /**
	 * The active parameter of the active signature. If omitted or the value
	 * lies outside the range of `signatures[activeSignature].parameters`
	 * defaults to 0 if the active signature has parameters.  [...]
	 */
	activeParameter?: uinteger;

However, we observed that VSCode does not follow this and will actually not highlight any parameter if activeParameter is outside of the range, and it is the case for the Rust LSP integration shown in my comment above.

Tracking LSP issue: microsoft/language-server-protocol#1271. In the future, null might be allowed as a value for activeParameter to explicitly mean that no parameter should be highlighted.

[rochala]

I've started tracking the upstream issue in language-server-protocol. If there is any update in the future, I'll make required changes / create a new ticket.