-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Lint dubious overload differs only in implicit [ci: last-only] #11033
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
Conversation
1d2e2ba
to
fc4e29e
Compare
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.
LGTM
The other possible advice is to ensure the implicit param has |
fc4e29e
to
09eda7c
Compare
This version takes nilary and implicit members, group by name for comparison, then looks at groups of more than one such-named members. Sorry, @lrytz |
Didn't review yet, but the current version has an issue
|
Sorry, I have another local commit to do accessors correctly. The desideratum is to warn for the private local in the test. Oh I see I was in the middle of an edit yesterday. It warns for
I guess this is what nowarn is for. |
c754eb2
to
a362aa7
Compare
^ | ||
t7415.scala:66: warning: Usages of value i will be easy to mistake for calls to def i(implicit t: T): Int, which has a single implicit parameter list. | ||
class S(i: Int) extends R(i) { // warn | ||
^ |
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.
Could tweak the message to say Usages of inherited member...
to clarify. The caret is at the class, but that is subtle. Cf new Derived1 {}
below
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 did not follow up, it was too subtle for me.
@@ -236,6 +237,7 @@ final class DoubleAccumulator | |||
} | |||
|
|||
/** Copies the elements in this `DoubleAccumulator` into an `Array[Double]` */ | |||
@nowarn // cat=lint-overload see toArray[B: ClassTag] | |||
def toArray: Array[Double] = { |
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.
This suggests a limitation of "manual specialization", namely the change in signature.
Would I ever want to acc.toArray[Any]
?
Not sure yet whether to suppress for this case? or is this exactly what the lint is for?
def ofInterest(tp: Type): Boolean = tp match { | ||
case mt: MethodType => mt.isImplicit | ||
case PolyType(_, rt) => ofInterest(rt) | ||
case _: NullaryMethodType | _ => true |
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.
case _: NullaryMethodType | _ => true | |
case _ => true |
_: NullaryMethodType | _
could be considered clarification or confusing, depending on the time of day..
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.
Normally I'd put it in /* _: NullaryMethodType |*/
and then a reviewer would say delete?
. I guess it could go in a regular line comment. This is an example where one forgets the model (that there is a nullary MT) if one has been away from it. Why doesn't the compiler help? I don't want to enumerate all the types I'm not interested in.
def isNilary(tp: Type): Boolean = tp match { | ||
case _: MethodType => false | ||
case PolyType(_, rt) => isNilary(rt) | ||
case _: NullaryMethodType | _ => true |
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.
case _: NullaryMethodType | _ => true | |
case _ => true |
case PolyType(_, rt) => ofInterest(rt) | ||
case _: NullaryMethodType | _ => true | ||
} | ||
def isNilary(tp: Type): Boolean = tp match { |
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.
Didn't we call foo
"nullary" and foo()
"nilary"? So this should be isNullary
?
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.
Maybe you're right. I thought nilary means paramss
is Nil
but maybe it's that it's ListOfNil
. Probably I just forgot.
The evil comment on NullaryMethodType
must be wrong then. What it says we mean by "nullary" is what we call "nilary". Then the comment in Namers in overridesNilary
is correct: it checks for MethodType
not NMT
because it wants "nilary" (neither nullary nor nelary).
@@ -160,6 +160,72 @@ abstract class RefChecks extends Transform { | |||
}) | |||
} | |||
} | |||
private def checkDubiousOverloads(clazz: Symbol): Unit = if (settings.warnDubiousOverload) { | |||
// nilary members or methods with leading implicit params |
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.
so this comment should say nullary. Just to confirm, we're saying the NullaryMethodType
is correctly named, and "nilary" was coined so we wouldn't have to rename it.
4ed5e86
to
9c6a721
Compare
Thanks, I fixed what would have been a terrible faux pas. |
9c6a721
to
d856b48
Compare
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.
Nice, thank you!
Fixes scala/bug#7415
TweaksExpands upon the truly retro (and pithy) retronym WIP.