EverCDDL: fix handling of type vs. group names#256
Merged
tahina-pro merged 14 commits intoJan 27, 2026
Conversation
… the fact from RFC 8610 Appendix C: Note that whether the name defined by a rule stands for a type or a group isn't always determined by syntax alone: e.g., "a = b" can make "a" a type if "b" is a type, or a group if "b" is a group. More subtly, in "a = (b)", "a" may be used as a type if "b" is a type, or as a group both when "b" is a group and when "b" is a type (a good convention to make the latter case stand out to the human reader is to write "a = (b,)"). (Note that the same dual meaning of parentheses applies within an expression but often can be resolved by the context of the parenthesized expression. On the more general point, it may not be clear immediately either whether "b" stands for a group or a type -- this semantic processing may need to span several levels of rule definitions before a determination can be made.)
necessary for array iterators with unit pair types
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.
#248 (comment) gives an example of CDDL specification that makes EverCDDL crash. This crash is due to the fact that the EverCDDL syntax parser tries to determine, at parsing time, whether an identifier will define a type or a group.
However, IETF RFC 8610 Appendix C says:
This means that determining whether a name will define a type or a group has to be done after the whole file has been parsed.
This PR fixes the EverCDDL syntax parser accordingly. First, we adapt the CDDL semantics to allow type names for
GDef, i.e. at places where a group is expected but the user gives a type name instead. Then, we fix the CDDL syntax parser to not record the type-or-group kind of an identifier, but to return a name in all cases where the parser cannot determine whether it is parsing a type or a group expression. Then, the parser generates a program where definitions can be of the forma = bwhereaandbare names, without any knowledge of whetheraandbshould be types or groups. Then, a simple algorithm resolves type-or-group kinds after all definitions have been parsed.This PR also introduces a loop detector, to reject a CDDL specification if it ends up producing a syntax parsing loop.
This is enough to have EverCDDL produce code for the large example at #248 (comment)