Fix #6816: Deny methods with implicit members from tpd.applyOverloaded #6923
Conversation
…loaded We cannot resolve implicit parameters outside Typer. Hence methods that require implicit parameters should not be considered.
| .map(denot => TermRef(receiver.tpe, denot.symbol)) | ||
| .filter(tr => typeParamCount(tr) == targs.length) | ||
| .filter { _.widen match { | ||
| case MethodTpe(_, _, x: MethodType) => !x.isImplicitMethod |
There was a problem hiding this comment.
What about curried methods that have implicit parameters as the 3rd parameter clause? Should we accept them? I guess there's no problem with those since we would not have to resolve them right away, right? If yes, it would be good to state this here as an explanation.
There was a problem hiding this comment.
There can be a problem... It looks like applyOverloaded resolves a method name looking only at the first argument group. E.g.:
def f(x: Int)(y: Int) given Z: Int
def f(x: String)(y: Int): Int
applyOverloaded("f", x: Any)In both cases, the logic above infers x.isImplicitMethod to be false, so it cannot differentiate and can select the one with the implicit args at the end. Which it will never be able to call if we are after Typer.
There was a problem hiding this comment.
Ah, OK. So we need to exclude all implicit methods, even of the implicit comes later.
There was a problem hiding this comment.
@odersky do you think this is no longer a problem?
2 participants
We cannot resolve implicit parameters outside Typer. Hence methods
that require implicit parameters should not be considered.