fix(rust): handle enums whose first or only tag is a default tag - #183
Merged
Conversation
Two related panics in the Rust backend for enums declaring a default (`= ..`) tag: - enum_is_complete called ranges.first().unwrap() on a vector that is empty when the enum declares no value or range tag. An enum with no value or range tags cannot cover the backing integer range, so it is not complete; guard with !ranges.is_empty(). - default_value matched on &tags[0] with Tag::Other(_) => todo!(), which is reached whenever the first declared tag is a default tag, even when value tags follow. Select the first tag that is not a default tag, and fall back to the default tag when it is the only tag declared. Adds both cases to the enum_declaration snapshot test. Fixes google#182
Collaborator
|
Looks good! Thank you for the patch :) |
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
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 #182.
Two related panics in the Rust backend for enums that declare a default (
= ..) tag.1.
enum_is_complete— emptyrangesenum_is_completefilter-maps the tags down toTag::Value/Tag::Range, then callsranges.first().unwrap(). An enum whose only tag is a default tag produces an empty vector, so the unwrap panics (mod.rs:997). An enum with no value or range tags cannot cover the backing integer range, so it is not complete — guarded with!ranges.is_empty().2.
default_value— first tag is a default tagdefault_valuematched on&tags[0], withast::Tag::Other(_) => todo!()(mod.rs:1075). That is reached whenever the first declared tag is a default tag, even when the enum also declares value tags:Per the discussion on #182, this now selects the first tag that is not a default tag, and falls back to the default tag when it is the only tag declared:
Testing
enum_declarationsnapshot test; snapshots regenerated withUPDATE_SNAPSHOTS=1.main(panicked at mod.rs:1075:31) and pass with this change.cargo test -p pdl-compiler: 171 passed, 0 failed.pdl-runtime.One note: the final match arm is unreachable for any parsed input, since the parser rejects an enum with no tags — I used
expectrather than leaving atodo!(), but happy to restructure it if you would prefer the arm be total.Found and checked while evaluating Rust verification tooling — midas-lex for the specification step, and a small Verus model of both obligations (the empty-
rangesindex, and that tag selection always yields a value) to confirm the patched forms are total.