Skip to content

False positive warning: Extension method f will never be selected #22705

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
OndrejSpanel opened this issue Mar 4, 2025 · 2 comments · Fixed by #22708
Closed

False positive warning: Extension method f will never be selected #22705

OndrejSpanel opened this issue Mar 4, 2025 · 2 comments · Fixed by #22708
Assignees
Labels
area:linting Linting warnings enabled with -W or -Xlint itype:bug
Milestone

Comments

@OndrejSpanel
Copy link
Member

Compiler version

3.7.0-RC1-bin-20250228-e592b37-NIGHTLY

Minimized code

object Native {
  class Obj:
    def f: String = "F"
}

object Types {

  opaque type Node = Native.Obj

  type S = Node

  object S:
    def apply(): S = new Node

  extension (s: S)
    def f: String = "S"
}

import Types.*

object Main {
  def main(args: Array[String]): Unit = {
    val v: S = S()
    println(v.f)
  }
}

Output

Extension method f will never be selected from type Node
because Node already has a member with the same name and compatible parameter types.
    def f: String = "S"

Expectation

The warning is wrong, the method is in fact used, as evidenced by the output of the program, which is S, not F. Moreover, the method f of the type Node cannot be used, as it is hidden inside an opaque type.

@OndrejSpanel OndrejSpanel added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Mar 4, 2025
@OndrejSpanel OndrejSpanel changed the title False positive warning: False positive warning: Extension method f will never be selected Mar 4, 2025
@soronpo
Copy link
Contributor

soronpo commented Mar 4, 2025

@som-snytt I think you made some changes in this, no?

@som-snytt
Copy link
Contributor

som-snytt commented Mar 4, 2025

Thanks, I'll take a look. There have been a couple of tweaks for interactions with opaque types. (By interactions, I mean bugs. The warning must be useful in some way, per the original ticket, but I'll have to refresh my memory about how it is conditioned by opaque types. I remember I commented that the "real desired feature" is a use site warning, where I write x.m intending an extension method that is not selected because the X acquired a member.)

IIRC this is not a lint warning, but I tagged it as such.

@som-snytt som-snytt added area:linting Linting warnings enabled with -W or -Xlint and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Mar 4, 2025
@som-snytt som-snytt self-assigned this Mar 4, 2025
@WojciechMazur WojciechMazur added this to the 3.7.0 milestone Mar 11, 2025
tgodzik pushed a commit to scala/scala3-lts that referenced this issue Apr 24, 2025
Fixes scala#22705
Fixes scala#22706 
Fixes scala#22727 

Follow-up to scala#22502 by inserting a
`dealias` when arriving at `target` type.

Refactored the body of `hidden` to make it easier to read. Adjusted the
doc for the same reason.

As a reminder to self, the original reason for special handling of
aliases was due to subclassing, but overrides are excluded. (One could
restore that warning for edge cases.)

The long doc explaining the handling of leading implicits is moved to
the end (as an appendix).

Despite best efforts, I was unable to make the doc longer than the code.
[Cherry-picked d362492]
tgodzik pushed a commit to scala/scala3-lts that referenced this issue Apr 24, 2025
Fixes scala#22705
Fixes scala#22706 
Fixes scala#22727 

Follow-up to scala#22502 by inserting a
`dealias` when arriving at `target` type.

Refactored the body of `hidden` to make it easier to read. Adjusted the
doc for the same reason.

As a reminder to self, the original reason for special handling of
aliases was due to subclassing, but overrides are excluded. (One could
restore that warning for edge cases.)

The long doc explaining the handling of leading implicits is moved to
the end (as an appendix).

Despite best efforts, I was unable to make the doc longer than the code.
[Cherry-picked d362492]
tgodzik pushed a commit to scala/scala3-lts that referenced this issue Apr 25, 2025
Fixes scala#22705
Fixes scala#22706 
Fixes scala#22727 

Follow-up to scala#22502 by inserting a
`dealias` when arriving at `target` type.

Refactored the body of `hidden` to make it easier to read. Adjusted the
doc for the same reason.

As a reminder to self, the original reason for special handling of
aliases was due to subclassing, but overrides are excluded. (One could
restore that warning for edge cases.)

The long doc explaining the handling of leading implicits is moved to
the end (as an appendix).

Despite best efforts, I was unable to make the doc longer than the code.
[Cherry-picked d362492]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:linting Linting warnings enabled with -W or -Xlint itype:bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants