Dealias before checking for member in lint #22708
Conversation
|
I did not yet re-examine aa44a3c |
som-snytt
force-pushed
the
issue/22705-extension-never-selected
branch
from
1725258 to
fb3cc68
Compare
|
I did not yet examine why it fixes the crash. |
| def memberMatchesMethod(member: Denotation) = | ||
| val memberIsImplicit = member.info.hasImplicitParams | ||
| val paramTps = | ||
| if memberIsImplicit then methTp.stripPoly.firstParamTypes | ||
| else methTp.explicit.firstParamTypes | ||
| inline def paramsCorrespond = | ||
| val memberParamTps = member.info.stripPoly.firstParamTypes | ||
| memberParamTps.corresponds(paramTps): (m, x) => | ||
| m.typeSymbol.denot.isOpaqueAlias == x.typeSymbol.denot.isOpaqueAlias && (x frozen_<:< m) | ||
| paramTps.isEmpty || memberIsImplicit && !methTp.hasImplicitParams || paramsCorrespond |
There was a problem hiding this comment.
The refactor looks correct to me. The only question is: were the isEmpty and length checks there for happy-path-optimization? I suppose that RefChecks is not a performance bottleneck, so it should be fine.
There was a problem hiding this comment.
I almost added a code comment at the time: paramTps.isEmpty was checked, and corresponds ensures same length, so the extra length compare was only because of lazyZip. My question was why didn't I make this edit last time I touched the code? I guess it's OK to focus on correctness first and then performance & style eventually.
There was a problem hiding this comment.
Simple coding decisions become harder when the domain model is harder (do I need dealias here? stripPoly there?) and still some mental friction in Scala 3 syntax (can I put a colon here? is this easy to read?).
som-snytt
force-pushed
the
issue/22705-extension-never-selected
branch
from
fb3cc68 to
f60f52e
Compare
Fixes #22705
Fixes #22706
Fixes #22727
Follow-up to #22502 by inserting a
dealiaswhen arriving attargettype.Refactored the body of
hiddento 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.