-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Emit generic signature for static forwarders to nullary methods #12710
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
Conversation
| else | ||
| MethodType(Nil, Nil, | ||
| eraseResult(sym.info.finalResultType.translateFromRepeated(toArray = sourceLanguage.isJava))) | ||
| eraseResult(rt.translateFromRepeated(toArray = sourceLanguage.isJava))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was needed for test run/t3452g
The backend calls TypeErasure.transformInfo(<Symbol TraversableLike.tail>, <Type ExprType(AbstractTrav[String])>).
Erasure should, I assume, continue to work on AbstractTrav[String] (which is rt here). Calling sym.info.finalResultType gives Repr which erases differently.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apparently that was intentionally changed in 76af6c5
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests passed...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, but at the very least we need to carefully check if this breaks binary compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very true. How could I do that? Compile the community build twice and do a jardiff?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ran dotty.communitybuild.CommunityBuildTestA twice; once with this PR, once with the line here reverted. This resulted in 14081 identical classfiles.
I also added a check to see when the old and new erasure are different and it only happened when called from the backend:
+ val a = eraseResult(rt.translateFromRepeated(toArray = sourceLanguage.isJava))
+ val b = eraseResult(sym.info.finalResultType.translateFromRepeated(toArray = sourceLanguage.isJava))
+ if (!(a =:= b) && !(new Exception).getStackTrace.exists(_.toString.contains("getStaticForwarderGenericSignature"))) then
+ throw new Exception(s"[ERASURE]\n- $a\n- $b\n- $tp\n- ${sym.showFullName}")
MethodType(Nil, Nil,
- eraseResult(rt.translateFromRepeated(toArray = sourceLanguage.isJava)))
+ a)I ran the sbt test and CommunityBuildTestA with this in place and did't see the exception showing up.
@smarter any other ideas?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I've run a similar test on the whole CI and it also didn't show any situation where the two types differed, this makes sense since the tp passed to eraseInfo should always be the symbol info at that point (it's only called from transformInfo which is only called from Erasure#transform, which always uses the symbol info except for java.lang.Object which is treated specially), so LGTM 🎇
smarter
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution!
Fixes #10347