Fix EnigmaWriterBase not writing missing destination namespace nest members#140
Open
Geolykt wants to merge 2 commits into
Open
Fix EnigmaWriterBase not writing missing destination namespace nest members#140Geolykt wants to merge 2 commits into
EnigmaWriterBase not writing missing destination namespace nest members#140Geolykt wants to merge 2 commits into
Conversation
…st members This happens when nest depth differs between source and destination names in enigma files. This can easily be provoked by making a class that was in its own compilation unit an inner class (at least insofar the destination namespace name is concerned) of an unrelated class. To give an example, the current behaviour is as follows: A `a` -> `b$c` mapping will be written as `CLASS a b`. A `a$b` -> `c$d$e` mapping will be written as `CLASS a$b c$d`. The new behaviour aligns with the expected behaviour of not voiding information. In the examples above, it will produce `CLASS a b$c` and `CLASS a$b c$d$e` respectively. Keep in mind that a lot of tooling doesn't use class names to evaluate the nest hosts. This commit does not change any behaviour regarding that, or in other words, just because the name indicates that a class is an inner class of another doesn't mean that it actually is considered to be as such according to javac or the JVM. Further, dependent projects such as enigma do not tolerate inner classes that have been created this way. However, prior to this commit Enigma's UI bugged out to the point where one cannot interact with these classes. Now the UI is bugged out, but the classes can at least be interacted with. However, this is an issue with either the reading process or some UI aspect within enigma, not within the enigma writing process (as far as I am concerned).
Why on earth does `publishToMavenLocal` not trigger the `check` task. Oh well
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This happens when nest depth differs between source and destination names in enigma files. This can easily be provoked by making a class that was in its own compilation unit an inner class (at least insofar the destination namespace name is concerned) of an unrelated class.
To give an example, the current behaviour is as follows: A
a->b$cmapping will be written asCLASS a b. Aa$b->c$d$emapping will be written asCLASS a$b c$d.The new behaviour aligns with the expected behaviour of not voiding information. In the examples above, it will produce
CLASS a b$candCLASS a$b c$d$erespectively. Thus it will be capable of roundtripping such mapping files.Keep in mind that a lot of tooling doesn't use class names to evaluate the nest hosts. This PR does not change any behaviour regarding that, or in other words, just because the name indicates that a class is an inner class of another doesn't mean that it actually is considered to be as such according to javac or the JVM.
Further, dependent projects such as Enigma do not tolerate inner classes that have been created this way. However, prior to this commit Enigma's UI bugged out to the point where one cannot interact with these classes. Now the UI is bugged out, but the classes can at least be interacted with. However, this is an issue with either the reading process or some UI aspect within enigma, not within the enigma writing process (as far as I am concerned).