-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Warn unused member of anonymous class #22729
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
Warn unused member of anonymous class #22729
Conversation
val V: Object {
def scalameta: String
} = new:
def scalameta = "4.0"
V.scalameta Maybe check for reflective selectable. Edit: or accept the limitation. |
fde7b34
to
345c16d
Compare
tests/warn/i22681.scala
Outdated
def run() = () | ||
def g = v // warn effectively private member is unused | ||
def t = v // nowarn | ||
def u = v // warn despite structural type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume that last warning is undesirable (false positive)? If yes, comment that it is so?
If not, why is it desirable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll comment. I almost added TODO
, but that only ensures that it is never done.
345c16d
to
c61872c
Compare
I added a very lazy (in the sense of slovenly) first cut at not warning about unused members that are leaked by a refinement. Probably it couldn't hurt because it is a niche case that could only result in false negatives. |
Fixes #22895 Fixes #22896 Follow-up to #22729 Follow-up to #22757 Since Scala 2, the check for unused parameters does not warn for an overriding method, since the signature is dictated by the overridden method. That behavior was intentionally omitted in 3.7 because it was introduced in Scala 2 before `@nowarn` and `@unused` were available. (The warning would be too noisy without mitigation.) A compiler option for these heuristics was tried in a previous commit, but reverted. (Compiler options are difficult to evolve once added.) So these commits restore this heuristic without further ado. An option for "strict mode" without allowances is future work. The other issue was that detecting an override in a Java parent did not work. The commit always checks `is(Override)` before searching for an overridden member, since it is not necessary to verify the modifier (which happens in RefChecks). Incorrect overriding would result in false negatives, which is acceptable since it will error later. Further asymmetry between checking implicit params and explicit class param accessors may or may not be dubious.
Fixes #22681
As noticed by tpolecat https://mastodon.social/@tpolecat/114078274060499612