Emit generic signature for static forwarders to nullary methods #12710
Conversation
| @@ -697,7 +697,7 @@ class TypeErasure(sourceLanguage: SourceLanguage, semiEraseVCs: Boolean, isConst | |||
| // See doc comment for ElimByName for speculation how we could improve this. | |||
| 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.
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.
Apparently that was intentionally changed in 76af6c5
There was a problem hiding this comment.
Sure, but at the very least we need to carefully check if this breaks binary compatibility.
There was a problem hiding this comment.
Very true. How could I do that? Compile the community build twice and do a jardiff?
There was a problem hiding this comment.
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.
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 🎇
Fixes #10347