Skip to content

Fix #6816: Deny methods with implicit members from tpd.applyOverloaded #6923

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.

Sign up for GitHub

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

Merged
merged 1 commit into from
Aug 30, 2019
Merged

Fix #6816: Deny methods with implicit members from tpd.applyOverloaded #6923

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions compiler/src/dotty/tools/dotc/ast/tpd.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1149,6 +1149,10 @@ object tpd extends Trees.Instance[Type] with TypedTreeInfo {
var allAlts = denot.alternatives
.map(denot => TermRef(receiver.tpe, denot.symbol))
.filter(tr => typeParamCount(tr) == targs.length)
.filter { _.widen match {
case MethodTpe(_, _, x: MethodType) => !x.isImplicitMethod
Copy link
Contributor

@odersky odersky Jul 31, 2019 •
edited
Loading

Choose a reason for hiding this comment

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

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

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.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, OK. So we need to exclude all implicit methods, even of the implicit comes later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@odersky do you think this is no longer a problem?

case _ => true
}}
if (targs.isEmpty) allAlts = allAlts.filterNot(_.widen.isInstanceOf[PolyType])
val alternatives = ctx.typer.resolveOverloaded(allAlts, proto)
assert(alternatives.size == 1,
Expand Down
14 changes: 14 additions & 0 deletions tests/run/i6816.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
trait Bar
trait Foo {
def ==(that: Foo)(implicit b: Bar): Boolean = ???
}

case class FooCC(f: Foo)

object Test {
def main(args: Array[String]): Unit = {
val foo1, foo2 = new Foo {}
assert(FooCC(foo1) == FooCC(foo1))
assert(FooCC(foo1) != FooCC(foo2))
}
}