Skip to content

NamedPartsAccumulator: also include bounds of uninstantiated type variables #750

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

Closed
wants to merge 3 commits into from

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