From 7f1b82b27cc37c21170ed6106382b9360829aea8 Mon Sep 17 00:00:00 2001 From: Guillaume Martres Date: Wed, 9 Oct 2024 01:54:09 +0200 Subject: [PATCH 1/2] Make overload pruning based on result types less aggressive `adaptByResult` was introduced in 2015 in 54835b6fb19ab0758c7503fb6f0e990ee4c25491 as a last step in overloading resolution: > Take expected result type into account more often for overloading resolution > > Previously, the expected result type of a FunProto type was ignored and taken into > account only in case of ambiguities. arrayclone-new.scala shows that this is not enough. > In a case like > > val x: Array[Byte] = Array(1, 2) > > we typed 1, 2 to be Int, so overloading resulution would give the Array.apply of > type (Int, Int*)Array[Int]. But that's a dead end, since Array[Int] is not a subtype > of Array[Byte]. > > This commit proposes the following modified rule for overloading resulution: > > A method alternative is applicable if ... (as before), and if its result type > is copmpatible with the expected type of the method application. > > The commit does not pre-select alternatives based on comparing with the expected > result type. I tried that but it slowed down typechecking by a factor of at least 4. > Instead, we proceed as usual, ignoring the result type except in case of > ambiguities, but check whether the result of overloading resolution has a > compatible result type. If that's not the case, we filter all alternatives > for result type compatibility and try again. In i21410.scala this means we end up checking: F[?U] <:< Int (where ?U is unconstrained, because the check is done without looking at the argument types) The problem is that the subtype check returning false does not mean that there is no instantiation of `?U` that would make this check return true, just that type inference was not able to come up with one. This could happen for any number of reason but commonly will happen with match types since inference cannot do much with them. We cannot avoid this by taking the argument types into account, because this logic was added precisely to handle cases where the argument types mislead you because adaptation isn't taken into account. Instead, we can approximate type variables in the result type to trade false negatives for false positives which should be less problematic here. Fixes #21410. --- .../src/dotty/tools/dotc/typer/Applications.scala | 10 +++++++--- tests/pos/i21410.scala | 12 ++++++++++++ tests/pos/i21410b.scala | 10 ++++++++++ 3 files changed, 29 insertions(+), 3 deletions(-) create mode 100644 tests/pos/i21410.scala create mode 100644 tests/pos/i21410b.scala diff --git a/compiler/src/dotty/tools/dotc/typer/Applications.scala b/compiler/src/dotty/tools/dotc/typer/Applications.scala index 17be2acc7378..de9caf05b550 100644 --- a/compiler/src/dotty/tools/dotc/typer/Applications.scala +++ b/compiler/src/dotty/tools/dotc/typer/Applications.scala @@ -2076,16 +2076,20 @@ trait Applications extends Compatibility { def resolveOverloaded(alts: List[TermRef], pt: Type)(using Context): List[TermRef] = record("resolveOverloaded") - /** Is `alt` a method or polytype whose result type after the first value parameter + /** Is `alt` a method or polytype whose approximated result type after the first value parameter * section conforms to the expected type `resultType`? If `resultType` * is a `IgnoredProto`, pick the underlying type instead. + * + * Using approximated result types is necessary to avoid false negatives + * due to incomplete type inference such as in tests/pos/i21410.scala. */ def resultConforms(altSym: Symbol, altType: Type, resultType: Type)(using Context): Boolean = resultType.revealIgnored match { case resultType: ValueType => altType.widen match { - case tp: PolyType => resultConforms(altSym, instantiateWithTypeVars(tp), resultType) - case tp: MethodType => constrainResult(altSym, tp.resultType, resultType) + case tp: PolyType => resultConforms(altSym, tp.resultType, resultType) + case tp: MethodType => + constrainResult(altSym, wildApprox(tp.resultType), resultType) case _ => true } case _ => true diff --git a/tests/pos/i21410.scala b/tests/pos/i21410.scala new file mode 100644 index 000000000000..c3ba3ea862bc --- /dev/null +++ b/tests/pos/i21410.scala @@ -0,0 +1,12 @@ +class A +object Test: + type F[X] <: Any = X match + case A => Int + + def foo[T](x: String): T = ??? + def foo[U](x: U): F[U] = ??? + + val x1 = foo(A()) + val y: Int = x1 + + val x2: Int = foo(A()) // error diff --git a/tests/pos/i21410b.scala b/tests/pos/i21410b.scala new file mode 100644 index 000000000000..a17ad59bc59e --- /dev/null +++ b/tests/pos/i21410b.scala @@ -0,0 +1,10 @@ +object Test: + def foo[T](x: Option[T]): T = ??? + def foo[T <: Tuple](x: T): Tuple.Map[T, List] = ??? + + val tup: (Int, String) = (1, "") + + val x = foo(tup) + val y: (List[Int], List[String]) = x + + val x2: (List[Int], List[String]) = foo(tup) // error From eafa761e45bda0912065ff1245322a2ba16e953f Mon Sep 17 00:00:00 2001 From: Guillaume Martres Date: Thu, 10 Oct 2024 19:41:58 +0200 Subject: [PATCH 2/2] Fix `isInlineable` check to work during overloading resolution Overloading may create temporary symbols via `Applications#resolveMapped`, these symbols do not carry the annotations from the original symbols which means the `isInlineable` would always return false for them. This matters because during the course of overloading resolution we might call `ProtoTypes.Compatibility#constrainResult` which special-cases transparent inline methods. Fixes a regression in Monocle introduced in the previous commit. --- compiler/src/dotty/tools/dotc/inlines/Inlines.scala | 8 +++++++- tests/pos/i21410c.scala | 11 +++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 tests/pos/i21410c.scala diff --git a/compiler/src/dotty/tools/dotc/inlines/Inlines.scala b/compiler/src/dotty/tools/dotc/inlines/Inlines.scala index aeecd9c376e3..7cb87f70803a 100644 --- a/compiler/src/dotty/tools/dotc/inlines/Inlines.scala +++ b/compiler/src/dotty/tools/dotc/inlines/Inlines.scala @@ -49,7 +49,13 @@ object Inlines: /** Can a call to method `meth` be inlined? */ def isInlineable(meth: Symbol)(using Context): Boolean = - meth.is(Inline) && meth.hasAnnotation(defn.BodyAnnot) && !inInlineMethod + meth.is(Inline) + && (meth.hasAnnotation(defn.BodyAnnot) + // Ensure `isInlineable` works with temporary symbols created during + // overloading resolution by `Applications#resolveMapped`. + // Testcase: tests/pos/i21410c.scala + || meth.hasAnnotation(defn.MappedAlternativeAnnot)) + && !inInlineMethod /** Should call be inlined in this context? */ def needsInlining(tree: Tree)(using Context): Boolean = tree match { diff --git a/tests/pos/i21410c.scala b/tests/pos/i21410c.scala new file mode 100644 index 000000000000..21f69fec20fa --- /dev/null +++ b/tests/pos/i21410c.scala @@ -0,0 +1,11 @@ +class AppliedPIso[A, B]() +case class User(age: Int) + +object Test: + extension [From, To](from: From) + def focus(): AppliedPIso[From, From] = ??? + transparent inline def focus(inline lambda: (From => To)): Any = ??? + + + val u = User(1) + val ap: AppliedPIso[User, User] = u.focus(_.age) // error