Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

som-snytt
Copy link
Contributor

@som-snytt som-snytt commented Mar 31, 2025

Fixes scala/bug#7415

Tweaks Expands upon the truly retro (and pithy) retronym WIP.

@scala-jenkins scala-jenkins added this to the 2.13.17 milestone Mar 31, 2025
@som-snytt som-snytt force-pushed the issue/7415-similar-overloads branch from 1d2e2ba to fc4e29e Compare March 31, 2025 00:53
@som-snytt som-snytt marked this pull request as ready for review March 31, 2025 05:21
Copy link
Member

@lrytz lrytz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@som-snytt som-snytt marked this pull request as draft March 31, 2025 16:09
@som-snytt
Copy link
Contributor Author

som-snytt commented Mar 31, 2025

The other possible advice is to ensure the implicit param has implicitNotFound message to explain what happens when it doesn't compile as expected.

@som-snytt som-snytt changed the title Lint dubious overload differs only in implicit Lint dubious overload differs only in implicit [ci: last-only] Apr 4, 2025
@som-snytt som-snytt force-pushed the issue/7415-similar-overloads branch from fc4e29e to 09eda7c Compare April 4, 2025 01:17
@som-snytt
Copy link
Contributor Author

som-snytt commented Apr 4, 2025

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

@som-snytt som-snytt marked this pull request as ready for review April 4, 2025 01:24
@som-snytt som-snytt requested a review from lrytz April 4, 2025 01:24
@lrytz
Copy link
Member

lrytz commented Apr 4, 2025

Didn't review yet, but the current version has an issue

[error] /home/jenkins/workspace/scala-2.13.x-validate-main/src/library/scala/collection/immutable/NumericRange.scala:492:40: Usages of value step will be easy to mistake for calls to private[this] val step: T, which has a single implicit parameter list.
[error]   class Inclusive[T](start: T, end: T, step: T)(implicit num: Integral[T])
[error]                                        ^

@som-snytt som-snytt marked this pull request as draft April 4, 2025 12:01
@som-snytt
Copy link
Contributor Author

som-snytt commented Apr 4, 2025

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 jdk.DoubleAccumulator which has toArray and toArray[B: ClassTag]. Hmm.

def toArray: Array[Double]
def toArray[B >: Double](implicit evidence$2: scala.reflect.ClassTag[B]): Array[B]

scala> acc.toArray

I guess this is what nowarn is for.

@som-snytt som-snytt force-pushed the issue/7415-similar-overloads branch from c754eb2 to a362aa7 Compare April 4, 2025 15:35
^
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
^
Copy link
Contributor Author

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

Copy link
Contributor Author

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] = {
Copy link
Contributor Author

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?

@som-snytt som-snytt marked this pull request as ready for review April 4, 2025 18:10
def ofInterest(tp: Type): Boolean = tp match {
case mt: MethodType => mt.isImplicit
case PolyType(_, rt) => ofInterest(rt)
case _: NullaryMethodType | _ => true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
case _: NullaryMethodType | _ => true
case _ => true

_: NullaryMethodType | _ could be considered clarification or confusing, depending on the time of day..

Copy link
Contributor Author

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
case _: NullaryMethodType | _ => true
case _ => true

case PolyType(_, rt) => ofInterest(rt)
case _: NullaryMethodType | _ => true
}
def isNilary(tp: Type): Boolean = tp match {
Copy link
Member

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?

Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@som-snytt som-snytt force-pushed the issue/7415-similar-overloads branch from 4ed5e86 to 9c6a721 Compare April 14, 2025 13:46
@som-snytt
Copy link
Contributor Author

Thanks, I fixed what would have been a terrible faux pas.

@som-snytt som-snytt force-pushed the issue/7415-similar-overloads branch from 9c6a721 to d856b48 Compare April 15, 2025 01:37
Copy link
Member

@lrytz lrytz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thank you!

@lrytz lrytz merged commit 38cbd77 into scala:2.13.x Apr 15, 2025
3 checks passed
@som-snytt som-snytt deleted the issue/7415-similar-overloads branch April 15, 2025 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

lint warning for parameterless method and method with an implicit parameter
3 participants