Skip to content

Transform annotations only if defined in current run #1241

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 3 commits into from
Apr 29, 2016

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Apr 29, 2016

There's no point transforming annotations that come from
classfiles. It's inefficient to do so and it's also risky
because it means we'd have to make sense of Scala-2 generated trees.

This should avoid the error in #1222.

Review by @DarkDimius

There's no point transforming annotations that come from
classfiles. It's inefficient to do so and it's also risky
because it means we'd have to make sense of Scala-2 generated trees.

This should avoid the error in scala#1222.
odersky added 2 commits April 29, 2016 10:23
As noticed by @smarter we need to ensure that classes owning
derived type params are completed, so that trees get the
proper symbol attachments. This triggered when I changed annotation
transformers - I have no idea whether how two could be related, though.
@odersky
Copy link
Contributor Author

odersky commented Apr 29, 2016

@smarter can you review last commit please?

@odersky
Copy link
Contributor Author

odersky commented Apr 29, 2016

The observed error was for compile-stdlib Junit test on my machine.

val annotTrees1 = annotTrees.mapConserve(annotationTransformer.macroTransform)
val annots1 = if (annotTrees eq annotTrees1) ref.annotations else annotTrees1.map(new ConcreteAnnotation(_))
val annots1 =
if (!ref.symbol.isDefinedInCurrentRun) ref.annotations // leave annotations read from class files alone
Copy link
Contributor

Choose a reason for hiding this comment

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

lgtm

@DarkDimius
Copy link
Contributor

DarkDimius commented Apr 29, 2016

@odersky, I'm not getting the change in 1c7c738. Would you mind providing either example or explanation? Thanks.

@odersky
Copy link
Contributor Author

odersky commented Apr 29, 2016

@DarkDimius It was something detected and diagnosed by @smarter. Maybe he can give an example. The test case he found was super-complicated though. The patch makes obvious sense; of course the class owner of type parameters needs to be completed before the parameters are type-checked. The only surprising thing is that this is not already always the case, but that sometimes an explicit ensureCompleted is required. @smarter knows better what scenario leads to this.

@@ -46,7 +46,11 @@ object desugar {
*/
override def ensureCompletions(implicit ctx: Context) =
Copy link
Member

Choose a reason for hiding this comment

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

The comment above could be updated to note that we also need to have the class itself completed.

@smarter
Copy link
Member

smarter commented Apr 29, 2016

I observed this when desugaring repeated parameters (but it can happen in a bunch of place in Desugar):

  1. In https://github.com/lampepfl/dotty/blob/96fcdd9da51e1febe9e320f774424b5ac3f8ff3d/src/dotty/tools/dotc/ast/Desugar.scala#L880-L885 we construct the untyped tree AppliedTypeTree(ref(seqType), t)) where ref(seqType) is a spliced type tree whose type is a TypeRef to Seq, notice that this does not involve forcing the info of Seq.
  2. When typing this AppliedTypeTree, we must first type the type constructor but there's nothing to do since it's a spliced type tree, the info of Seq is still unforced.
  3. Then we need to type the argument of the AppliedTypeTree, this requires forcing the info of the corresponding type parameter (Seq$$A).
  4. Forcing the info of Seq$$A fails in https://github.com/lampepfl/dotty/blob/96fcdd9da51e1febe9e320f774424b5ac3f8ff3d/src/dotty/tools/dotc/typer/Typer.scala#L854-L867 because the info of Seq is still unforced, so the OriginalSymbol attachment is missing.

So I see two ways to fix this: either make sure in Desugar that we never construct an AppliedTypeTree without forcing the info of the type constructor or changing the definition of ensureCompletions to ensure that, which is what 1c7c738 does and is very similar to what I did locally.

LGTM.

@DarkDimius DarkDimius merged commit f9858a4 into scala:master Apr 29, 2016
@allanrenucci allanrenucci deleted the fix-#1222 branch December 14, 2017 16:59
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