Add support for enums with negative discriminants #4204
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.
fixes #2313
This adds support for enums with negative discriminants and slightly improves error messages.
Honestly, implementing this was pretty simple. I don't have too much to say about this, just a few notes on implementation details:
Within the serialized data for ASTs and descriptors, variants are still passed around as
u32
. Instead of representing the actual value, they now represent the bits of thei32
oru32
value. Which one it is depends on the newsigned: bool
field. I wanted to usei64
, but this doesn't work well withinform
or other serialization, so I opted to "decode" the variant values to i64 on the CLI side just before JS code gen.Holes. The parser now makes the assumption that there are <2^31 variants to make it easier to find holes. This also has the nice property that signedness does not affect the hole, which makes working with them a lot easier. In fact, I didn't even have to change any of the code for enum holes.
This is technically a breaking change, but, you know, who has that many variants anyway?