Skip to content

Fix #10123: Try to fully define qualifier type #10205

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.

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 5 commits into from
Nov 23, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
22 changes: 22 additions & 0 deletions compiler/src/dotty/tools/dotc/typer/Inferencing.scala
Original file line number Diff line number Diff line change
Expand Up @@ -81,6 +81,28 @@ object Inferencing {
if (depVars.nonEmpty) instantiateSelected(tp, depVars.toList)
}

/** If `tp` is top-level type variable with a lower bound in the current constraint,
* instantiate it from below. We also look for TypeVars whereever their instantiation
* could uncover new type members.
*/
def couldInstantiateTypeVar(tp: Type)(using Context): Boolean = tp.dealias match
Copy link
Member

Choose a reason for hiding this comment

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

I don't think that's quite right either since given ?F[?A] I need to instantiate at least ?F, and then if it's a type lambda I may or may not need to instantaite ?A too. Also since this is a selection prefix, we want to avoid Nothing if possible, in fact in all situation where we're trying to avoid Nothing, we only want to avoid it at the top-level. This is what I came up last time I was looking at this: https://github.com/dotty-staging/dotty/blob/63c7bad7f01c5fccf4620376aa7c8f70bc90b66d/compiler/src/dotty/tools/dotc/typer/Inferencing.scala#L49-L83
but I was a bit concerned that this duplicated code from IsFullyDefinedAccumulator.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right. In this particular case we need to instantiate the ?F. The ?A can come later when we recursively call typedSelect on the new call. I have taken your changes and adapted them to couldInstantiateTypeVar. You don't need to check for LazyRef in either code, since that is already eliminated by dealias. On the other hand, one should look inside AndTypes, OrTypes, and AnnotatedTypes.

case tvar: TypeVar
if !tvar.isInstantiated
&& ctx.typerState.constraint.contains(tvar)
&& tvar.hasLowerBound =>
tvar.instantiate(fromBelow = true)
Comment on lines +92 to +93
Copy link
Member

Choose a reason for hiding this comment

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

When trying to select from something that doesn't have a lower-bound, rather than giving up I think it makes sense to try the upper bound, since it might be precise enough, also we could take instDireciton into account to be closer to the normal behavior of isFullyDefined:

Suggested change
&& tvar.hasLowerBound =>
tvar.instantiate(fromBelow = true)
=>
val direction = instDirection(tvar.origin)
tvar.instantiate(fromBelow = direction < 0 || tvar.hasLowerBound)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am not sure that will help. The situation is that we try to select a member that does not exist on the type variable. Instantiating to the upper bound would not help in this case. If the member existed on the upper bound, it would also exist on the variable itself.

Copy link
Member

Choose a reason for hiding this comment

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

If the member existed on the upper bound, it would also exist on the variable itself.

Ah indeed, because goParam in findMember will recurse on the upper bound, but isn't that actually problematic? If I have a selection x.foo where the type of x is a type variable ?T <: B, we'll end up selecting some overload of B#foo, but it's possible that ?T is then instantiated to some more precise type which contains another overload of foo (or an override with a more precise result type), meaning that the member selected is not preserved by retyping (in practice our ReTyper will keep the original selection, but this still seems like a source of confusion since the meaning of the code is not apparent from the types the user sees).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This could be a problem. But (1) it's not related to this issue.(2) I don't know how to solve it.

Copy link
Member

Choose a reason for hiding this comment

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

I think the change I'm proposing together with removing the recursion on the upper bound in goParam would solve that issue, but I agree this can be treated separately from this PR.

true
case AppliedType(tycon, _) =>
couldInstantiateTypeVar(tycon)
case RefinedType(parent, _, _) =>
couldInstantiateTypeVar(parent)
case tp: AndOrType =>
couldInstantiateTypeVar(tp.tp1) || couldInstantiateTypeVar(tp.tp2)
case AnnotatedType(tp, _) =>
couldInstantiateTypeVar(tp)
case _ =>
false

/** The accumulator which forces type variables using the policy encoded in `force`
* and returns whether the type is fully defined. The direction in which
* a type variable is instantiated is determined as follows:
Expand Down
4 changes: 4 additions & 0 deletions compiler/src/dotty/tools/dotc/typer/TypeAssigner.scala
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,7 @@ import config.Printers.typr
import ast.Trees._
import NameOps._
import ProtoTypes._
import Inferencing.couldInstantiateTypeVar
import collection.mutable
import reporting._
import Checking.{checkNoPrivateLeaks, checkNoWildcard}
Expand Down Expand Up @@ -159,6 +160,9 @@ trait TypeAssigner {
TryDynamicCallType
else if (qualType.isErroneous || name.toTermName == nme.ERROR)
UnspecifiedErrorType
else if couldInstantiateTypeVar(qualType) then
// try again with more defined qualifier type
selectionType(tree, qual1)
else if (name == nme.CONSTRUCTOR)
errorType(ex"$qualType does not have a constructor", tree.srcPos)
else {
Expand Down
File renamed without changes.
19 changes: 19 additions & 0 deletions tests/pos/i10123.scala
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
class D
class C[+T](x: T)

class Foo() {
val status: Int = 0
}

object Main {
implicit class RichC[T](c: C[T]) {
def await(implicit d: D = ???): T = ???
}

def test1: Int = {
val foo = new C(new Foo()).await
foo.status
}

val test2 = new C(new Foo()).await.status
}
22 changes: 22 additions & 0 deletions tests/pos/i9567.scala
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
// object Test {
// val x: Int => Int = identity
// }

trait Foo[F[_]] {
def foo[G[x] >: F[x]]: G[Unit]
}

trait M[A] {
def bla: Int = 1
def baz(f: Int => Int): Int = f(1)
}

object Test {
def bar(x: Foo[M]): Unit = {
// error: value bla is not a member of G[Unit], where: G is a type variable with constraint >: M and <: [x] =>> Any
x.foo.bla

// error: value bla is not a member of G[Unit], where: G is a type variable with constraint >: M and <: [x] =>> Any
x.foo.baz(x => x)
}
}