fix(ast/enum_parser): allow arbitrary nesting of '*' and '[]' in variant field types#61
Open
bbodi wants to merge 1 commit into
Open
fix(ast/enum_parser): allow arbitrary nesting of '*' and '[]' in variant field types#61bbodi wants to merge 1 commit into
bbodi wants to merge 1 commit into
Conversation
…ant field types The enum parser's parseTypeExpr accepted any number of '*' prefixes, but only a single trailing '[]', and only in the order `<pointers><slice><name>`. Field declarations such as `[]*Foo`, `[][]Foo`, or `[][]*Foo` therefore tripped the parser, which surfaced downstream as a confusing "parse error: ... expected declaration, found enum" message at the enum's opening line. Replace the two ad-hoc loops with a single loop that consumes '*' and '[]' tokens in any order and any count, matching what the rest of the pipeline already accepts for ordinary field types. Tests cover plain, pointer (*T, **T), slice ([]T, [][]T), mixed (*[]T, []*T, [][]*T), generic slice ([]int) prefixes for both struct-style and tuple-style variants, plus end-to-end regressions through TransformSource for the previously failing `[]*Name` and multi-line variant bodies.
bbodi
added a commit
to bbodi/dingo
that referenced
this pull request
May 18, 2026
…g#62 into fork main Combines all four currently open pull requests against MadAppGang/dingo into the local fork's main so downstream work (e.g. the nodes.go cascade fix) can build on top of all of them without one-by-one branch juggling. The upstream PRs remain unaffected because their base branch is MadAppGang/dingo:main, not bbodi/dingo:main. Included: MadAppGang#59 fix(ast/transform): recognise method receiver param lists for type annotations MadAppGang#60 test(tokenizer): cover ENUM and GUARD keywords at both surfaces MadAppGang#61 fix(ast/enum_parser): allow arbitrary nesting of '*' and '[]' in variant field types MadAppGang#62 feat(feature): add Validator plugin extension and character-level pre-transform phase
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
1 participant
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.
Summary
EnumParser.parseTypeExprwas conservative about how it parsed type prefixes on struct- and tuple-variant fields. It accepted any number of*prefixes followed by at most one[], and only in the order<pointers><slice><name>. So:*T**T*[]T[]T[]*T[][]T[][]*TWhen the parser hit a rejected prefix, the failure surfaced two phases later as a confusing
pointing at the enum's opening line — making the real cause hard to spot.
The fix replaces the two ad-hoc loops with a single loop that consumes
*and[]in any order and any count, matching what the rest of the Dingo pipeline already accepts for ordinary field types.Test plan
go test ./pkg/ast/...(newTestEnumParser_TypePrefixescovers 9 prefix shapes for struct variants,TestEnumParser_TupleTypePrefixescovers 2 for tuple variants)go test ./...(full suite stays green; no other parser/codegen regression)TransformSourceregression for the previously failing[]*Namefield plus a multi-line variant body🤖 Generated with Claude Code