Improve overloading resolution if expected type is not FunProto #14733
Conversation
If expected type is a selection proto or similar we picked all alternatives that were compatible with it. But if the expected type was meant to be used after extension method expansion, then no alternative would be classified as compatible. We now drop all method alternatives in this case. If only one alternative remains, we pick that one. Fixes scala#14279
| // pick any alternatives that are not methods since these might be convertible | ||
| // to the expected type, or be used as extension method arguments. | ||
| val convertible = alts.filterNot(alt => | ||
| normalize(alt, IgnoredProto(pt)).widenSingleton.isInstanceOf[MethodType]) |
There was a problem hiding this comment.
Is using normalize really needed here or could we do:
| normalize(alt, IgnoredProto(pt)).widenSingleton.isInstanceOf[MethodType]) | |
| alt.widenSingleton.isInstanceOf[MethodOrPoly]) |
There was a problem hiding this comment.
It's needed for skipping using clauses
There was a problem hiding this comment.
I see. normalize will create fresh type variables for PolyTypes, they'll be gc'ed eventually but if we wanted to avoid creating them in the first place we could perhaps have a stripPolyAndImplicit method, or add a flag to normalize for situations where we don't keep around its result.
| // pick any alternatives that are not methods since these might be convertible | ||
| // to the expected type, or be used as extension method arguments. | ||
| val convertible = alts.filterNot(alt => | ||
| normalize(alt, IgnoredProto(pt)).widenSingleton.isInstanceOf[MethodType]) |
There was a problem hiding this comment.
I see. normalize will create fresh type variables for PolyTypes, they'll be gc'ed eventually but if we wanted to avoid creating them in the first place we could perhaps have a stripPolyAndImplicit method, or add a flag to normalize for situations where we don't keep around its result.
I the inefficiency won't matter since this case is executed rarely. In fact not executing this case caused the error that was fixed. So that should be the only time so far we fall into this case. |
If expected type is a selection proto or similar we picked all alternatives
that were compatible with it. But if the expected type was meant to be
used after extension method expansion, then no alternative would be classified
as compatible.
We now drop all method alternatives in this case. If only one alternative remains,
we pick that one.
Fixes #14729