Only generate generic signature if it differs from descriptor#25880
Only generate generic signature if it differs from descriptor#25880SolalPirelli wants to merge 2 commits intoscala:mainfrom
Conversation
| val gensig = getGenericSignatureHelper(sym, moduleClass, memberTpe).orNull | ||
| if gensig == descriptor then null | ||
| else gensig | ||
| else null |
There was a problem hiding this comment.
Not pretty, but this method belongs in the lowest circle of Hell anyway and should disappear if I ever have the courage to clean up mirror generic signature generation.
|
In Scala 2 this is handled by |
|
I could've added another special case but I didn't get why we even have this "needs generic signature" test, there are probably other such cases of methods that shouldn't have a generic signature but do right now, it's hard to test, and all tests pass with this change. Is there some drawback to the "always generate unless it's been turned off or it's unneeded" approach that I'm not aware of? |
But it shouldn't need a special case;
I don't know either... maybe git history would reveal something. From the top of my head what you say makes sense, we don't need a signature that duplicates the descriptor. But it feels a bit like patching things up given there's the |
The reason it's currently true isn't the type itself but the fact that method is considered a bridge, and for some reason we generate generic signatures for all such methods. (I think it might also have the artifact flag... I don't remember exactly since I looked at it) As to why we check these flags, it dates back to the introduction of GenASM (i.e., it was in the commit that added that file), so I guess we'll never know 😅 |
SolalPirelli
added
the
needs-squashing
2 participants
Fixes #10837
Perhaps someone can tell me why this is a bad idea.
How much have you relied on LLM-based tools in this contribution?
Not at all
How was the solution tested?
Manual tests because writing automated tests is impractical, described below (in detail)
I ran
scalacon the repro from the issue and looked at the output ofjavap -von bothAandA$. I don't know how to check for the existence of a signature in a non-generic method programmatically without importingASMin the test which seems too heavyweight.