Skip to content

Conversation

@smarter
Copy link
Member

@smarter smarter commented Aug 5, 2015

This PR depends on #749


In the following code:

class Foo[T](x: T)
val z = {
  class X
  new Foo(new X)
}

When we call Typer#ensureNoLocalRefs on the block, its type is:

Foo[T] where T <: X

Before this commit, Typer#escapingRefs returned the empty set for this
type since T is not instantiated yet, so the type was kept as is, and X escaped:

val z: Foo[X] = {
  class X
  new Foo(new X)
}

We avoid this by inspecting the bounds of uninstantiated type variables
in NamedPartsAccumulator which is used by Typer#escapingRefs.


@odersky : Please review. I'm not sure if this is the proper way to fix this, maybe the instantiation of type parameters could try to avoid types which are not in scope?

smarter added 3 commits August 5, 2015 22:30
In 0efa171 I changed the definition of
NamedPartsAccumulator to exclude lower bounds as this is required for the
implicit search, but NamedPartsAccumulator is also used by
Typer#escapingRefs so in the following code:
  class Foo[T]
  val z = {
    class C

    ??? : Foo[_ >: C]
  }
the type of z was inferred to be Foo[_ >: C] instead of Foo.

To avoid this, NamedPartsAccumulator will only exclude lower bounds if
the parameter excludeLowerBounds is explicitely set to true.

No test because there is no way to detect that a type has escaped, this
might be something that could be added to TreeChecker.
…iables

In the following code:
  class Foo[T](x: T)
  val z = {
    class X
    new Foo(new X)
  }
When we call `Typer#ensureNoLocalRefs` on the block, its type is:
  Foo[T] where T <: X
Before this commit, `Typer#escapingRefs` returned the empty set for this
type since T is not instantiated yet, so the type was kept as is, and X escaped:
  val z: Foo[X] = {
    class X
    new Foo(new X)
  }
We avoid this by inspecting the bounds of uninstantiated type variables
in `NamedPartsAccumulator` which is used by `Typer#escapingRefs`.
@odersky
Copy link
Contributor

odersky commented Aug 8, 2015

I have to think about it. Maybe we should instantiate those type variables that have escaping refs as bounds.

@smarter
Copy link
Member Author

smarter commented Aug 9, 2015

I just realized that with the instantiation scheme I proposed in #739 and prototyped in https://github.com/smarter/dotty/commits/fix/tp-instantiation-scheme, this issue does not occur anymore because the type parameters of a method are always instantiated early enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants