Skip to content

Alternative fix for #10044 #15129

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 4 commits into from
May 18, 2022
Merged

Alternative fix for #10044 #15129

merged 4 commits into from
May 18, 2022

Conversation

odersky
Copy link
Contributor

@odersky odersky commented May 6, 2022

This is a better alternative to fix #10044 than #15120. Unfortunately, it fails
dotty.tools.dotc.BootstrappedOnlyCompilationTests.runWithCompiler in the
tasty interpreter test. Here I see:

-- Error: tests/run-custom-args/tasty-interpreter/interpreter/jvm/Interpreter.scala:13:6 -------------------------------
13 |  val jvmReflection = new JVMReflection(using q)
   |      ^
   |compiler bug: created invalid generic signature for getter jvmReflection in scala.tasty.interpreter.jvm.Interpreter
   |signature: ()Lscala/tasty/interpreter/jvm/JVMReflection<()Ljava/lang/Object;>;
   |if this is reproducible, please report bug at https://github.com/lampepfl/dotty/issues
Error while emitting Interpreter.scala

If I turn on printing in line 2583 in Types.scala, I see the last output as follows:

overwrite TermRef(ThisType(TypeRef(ThisType(TypeRef(NoPrefix,module class jvm)),class Interpreter)),method q) / getter q, class dotty.tools.dotc.core.Denotations$UniqueRefDenotation with getter q at 106

So it does overwrite, and the overwrite looks OK, but somehow changing a SymDenotation with a UniqueRefDenotation for the same symbol messes up generic signature generation.

Can someone help me digging deeper here?

@odersky
Copy link
Contributor Author

odersky commented May 6, 2022

I think I found and fixed the bug with signature generation.

@odersky
Copy link
Contributor Author

odersky commented May 17, 2022

@smarter ping for review

odersky added 3 commits May 17, 2022 19:00
This addresses the specific problem raised by scala#10044: A denotation
of a NamedType goes from a UniqueRefDenotation to a SymDenotation
after erasure and is then not reset to the original since the
SymDenotation is valid at all phases. We remember in this case
in the NamedType the first phase in which the SymDenotaton is valid
and force a recompute in earlier phases.

Fixes scala#10044
Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

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

Otherwise LGTM, I rebased and applied the suggested comment.

denot match
case denot: SymDenotation
if denot.validFor.firstPhaseId < ctx.phase.id
&& lastDenot != null
Copy link
Member

Choose a reason for hiding this comment

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

I'm not completely sure that we won't run into issues where lastDenot didn't exist, but we need to get the denotation at an earlier phase in a subsequent run or via time-travelling. How expensive would it be to always create UniqueRefDenotation after erasure?

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 prefer caution here. I don't have the time to look into a change like this, which looks risky to me.

@smarter smarter assigned odersky and unassigned smarter May 17, 2022
@odersky odersky merged commit ae5f986 into scala:main May 18, 2022
@odersky odersky deleted the fix-10044-v2 branch May 18, 2022 14:11
@Kordyjan Kordyjan added this to the 3.2.0 milestone Aug 1, 2023
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.

REPL: chained extension methods on opaque types can only be called once
3 participants