SI-8900 Don't assert !isDelambdafyFunction, it may not be accurate #4049
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I'd like to figure what the macro was doing to generated the name that tripped this, and add a test case. |
|
If you don't want $lambda to appear in class names, nobody can use any identifiers which begin with lambda. |
|
Here's a test case. Look, Ma, no macros. We could simply tighten up those name based checks to look only at We could also switch over to using flags or symbol annotations for these, although if we do we have to think/test carefully separate compilation scenarios. No doubt calling your package or function |
The implementations of isAnonymousClass, isAnonymousFunction, isDelambdafyFunction and isDefaultGetter check if a specific substring (eg "$lambda") exists in the symbol's name. SI-8900 shows an example where a class ends up with "$lambda" in its name even though it's not a delambdafy lambda class. In this case the conflict seems to be introduced by a macro. It is possible that the compiler itself never introduces such names, but in any case, the above methods should be implemented more robustly. This commit is band-aid, it fixes one specific known issue, but there are many calls to the mentioned methods across the compiler which are potentially wrong. Thanks to Jason for the test case!
|
LGTM |
|
PLS REBUILD ALL |
|
(kitty-note-to-self: ignore 59735555) |
|
PLS REBUILD ALL IDE fails with: I hope this one will just go away... |
|
(kitty-note-to-self: ignore 59757313) |
|
I hit this with the repl update to javap -fun. Naturally I named something lambdaMethods. Wikipedia article on lambda has a secondary reference that says the ancient pronunciation was labda, so I went with that. I can't write lambda without thinking of baby sheep. |
|
PLS REBUILD ALL |
|
(kitty-note-to-self: ignore 59811500) |
gkossakowski
added a commit
that referenced
this pull request
Oct 20, 2014
SI-8900 Don't assert !isDelambdafyFunction, it may not be accurate
This was referenced Apr 7, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The implementations of isAnonymousClass, isAnonymousFunction,
isDelambdafyFunction and isDefaultGetter check if a specific substring
(eg "$lambda") exists in the symbol's name.
SI-8900 shows an example where a class ends up with "$lambda" in its
name even though it's not a delambdafy lambda class. In this case the
conflict seems to be introduced by a macro. It is possible that the
compiler itself never introduces such names, but in any case, the
above methods should be implemented more robustly.
This commit is band-aid, it fixes one specific known issue, but there
are many calls to the mentioned methods across the compiler which
are potentially wrong.