Skip to content

TypedTreeCopier makes incorrect assumption when deciding if Block or If nodes need to be retyped #444

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
smarter opened this issue Mar 30, 2015 · 6 comments · Fixed by #5958

Comments

@smarter
Copy link
Member

smarter commented Mar 30, 2015

For blocks, from tpd.scala:

tree match {
  case tree: Block if (expr.tpe eq tree.expr.tpe) => tree1.withTypeUnchecked(tree.tpe)
  case _ => ta.assignType(tree1, stats, expr)
}

This assumes that tree.tpe and tree.expr.tpe are in sync, but with a block like:

{
  val y: Position = new Position(1)
  y
}

Then tree.expr.tpe will be a TermRef but tree.tpe will be a widened version of that type since the TermRef should not escape the scope of the block. This means that if the info of y is changed by DenotTransformer#transform:

  • tree.expr.tpe will still be a TermRef
  • tree.expr.tpe.widen will be changed
  • tree.tpe will not be changed, is now incorrect, and needs to be retyped.

This happens in phase ElimErasedValueType in my implementation of value classes, see https://github.com/smarter/dotty/tree/add/value-classes%2Bcpy-bug and reproduce the bug by running:

> run -Ycheck:elimErasedValueType tests/pos/vcblock.scala
> run -Ycheck:elimErasedValueType tests/pos/vcif.scala

And note that the errors disappear if you always retype Block and If: https://github.com/smarter/dotty/tree/add/value-classes%2Bcpy-bug%2Bretype

Assigned to @DarkDimius .

@DarkDimius DarkDimius self-assigned this Mar 30, 2015
@DarkDimius
Copy link
Contributor

@smarter, in future, can you please put value-classes-related tests into separate folder? Like the one for tailrec

@smarter
Copy link
Member Author

smarter commented Mar 30, 2015

Sure.

DarkDimius added a commit to dotty-staging/dotty that referenced this issue Mar 30, 2015
@DarkDimius
Copy link
Contributor

@smarter see PR

@smarter
Copy link
Member Author

smarter commented Nov 3, 2016

@felixmulder Any reason this was closed? The PR was not applied, though I don't remember why we decided to not merge it at the time

@smarter smarter reopened this Nov 3, 2016
@felixmulder
Copy link
Contributor

I'm not sure why this was closed - maybe I thought the fix was merged (or maybe tool magic). Could we get a comment on why the fix wasn't merged @DarkDimius ?

DarkDimius added a commit to dotty-staging/dotty that referenced this issue May 23, 2017
DarkDimius added a commit to dotty-staging/dotty that referenced this issue May 23, 2017
Where did they disappear to?
OlivierBlanvillain pushed a commit to dotty-staging/dotty that referenced this issue May 23, 2017
OlivierBlanvillain pushed a commit to dotty-staging/dotty that referenced this issue May 23, 2017
Where did they disappear to?
DarkDimius added a commit to dotty-staging/dotty that referenced this issue May 24, 2017
DarkDimius added a commit to dotty-staging/dotty that referenced this issue May 24, 2017
Where did they disappear to?
@odersky
Copy link
Contributor

odersky commented Jan 27, 2018

A @smarter Can you check whether this is still an issue?

@odersky odersky assigned smarter and unassigned DarkDimius Jan 27, 2018
liufengyun pushed a commit to dotty-staging/dotty that referenced this issue Feb 20, 2019
odersky added a commit that referenced this issue Feb 21, 2019
Fix #444: be more conservative on when Block and If types should be recomputed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants