Overriding java methods containing varargs gives warning

[Arthurm1]

Reproduction steps

Scala version: 2.13.8

Override java.nio.file.Path as follows...

import java.nio.file.Path
import java.nio.file.FileSystem
import java.net.URI
import java.nio.file.LinkOption
import java.nio.file.{WatchKey, WatchService}
import java.nio.file.WatchEvent.{Kind, Modifier}

class FooPath extends Path {

  override def getFileSystem(): FileSystem = { null }

  override def isAbsolute(): Boolean = { false }

  override def getRoot(): Path = { null }

  override def getFileName(): Path = { null }

  override def getParent(): Path = { null }

  override def getNameCount(): Int ={ 0 }

  override def getName(x$1: Int): Path ={ null }

  override def subpath(x$1: Int, x$2: Int): Path = { null }

  override def startsWith(x$1: Path): Boolean = { false }

  override def endsWith(x$1: Path): Boolean = { false }

  override def normalize(): Path = { null }

  override def resolve(x$1: Path): Path = { null }

  override def relativize(x$1: Path): Path = { null }

  override def toUri(): URI = { null }

  override def toAbsolutePath(): Path = { null }

  override def toRealPath(x$1: LinkOption*): Path = { null }

  override def register(x$1: WatchService, x$2: Array[Kind[_ <: Object]], x$3: Modifier*): WatchKey = { null }

  override def compareTo(x$1: Path): Int = { 0 }
}

Problem

The toRealPath and register methods have warnings that the varargs parameters are not used. Here's a screenshot in Metals...

The methods that don't contain vararg params correctly have no warnings.

Also - Metals doesn't show codelens for the varargs methods for goto parent. Not sure if this stems from the same place as the warnings.

It's fine when overriding a Scala trait with varargs - only overriding a Java class seems to be an issue.

See https://github.com/scalameta/metals/issues/3939 for original bug report at Metals.

[tgodzik]

When investigating the issue in semanticdb I saw that symbol.overridenSymbols doesn't yield the parent method, so this might be related to the way the parameters are compared when looking for parent symbols.

[som-snytt]

Note that current -Wunused stops warning on the example because of the "trivial" RHS.

[som-snytt]

I will PR an OverridingPairs.Cursor that handles the special case of Scala varargs overriding Java. The bridge is emitted in RefChecks, which RefChecks relies on while RefChecking. Bridges for @varargs are at erasure. A different approach to this issue would be to move the warning to RefChecks.

Also I appreciated the Java varargs pun: as follows...

[Arthurm1]

I will PR an OverridingPairs.Cursor that handles the special case of Scala varargs overriding Java. The bridge is emitted in RefChecks, which RefChecks relies on while RefChecking. Bridges for @varargs are at erasure. A different approach to this issue would be to move the warning to RefChecks.

Thanks!

Also I appreciated the Java varargs pun: as follows...

I only wish it was intentional

[som-snytt]

I embraced the Path example, but learned there are default methods, as noticed by test running on JVM 8.

[Arthurm1]

How about java.nio.file.Watchable. It's varargs all the way down.

[SethTisue]

@som-snytt is your PR still something you might return to? or should I un-assign you and/or put a "help wanted" label?

[som-snytt]

Neither PR is very satisfying: the first is many LOC for a little issue; the second (linting later) is a bigger change albeit with tradeoffs (such as linting macros). Maybe macros could be linted at expansion. I will resubmit.