Skip to content

Conversation

@alexcrocha
Copy link

@alexcrocha alexcrocha commented Nov 27, 2025

Refactor the previous implementation of Symbol/Keyword handling to treat them as first-class nodes in the build configuration.

Keyword and Symbol represent identifiers (interned strings), not traditional AST nodes. However, the C parser defines them in rbs_node_type (as RBS_KEYWORD and RBS_AST_SYMBOL) and treats them as nodes (rbs_node_t*) in many contexts (lists, hashes).

Instead of manually defining RBSSymbol/RBSKeyword structs, we now inject them into the config.yml node list in build.rs. This allows them to be generated as SymbolNode/KeywordNode variants in the Node enum, enabling polymorphic handling (in Node lists and Hashes)

Refactor the previous implementation of Symbol/Keyword handling to treat
them as first-class nodes in the build configuration.

Instead of manually defining RBSSymbol/RBSKeyword structs, we now inject
them into the config.yml node list in build.rs. This allows them to be
generated as SymbolNode/KeywordNode variants in the Node enum, enabling
polymorphic handling (in Node lists and Hashes)
Copy link
Author

alexcrocha commented Nov 27, 2025

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

@alexcrocha alexcrocha mentioned this pull request Nov 27, 2025
@alexcrocha alexcrocha marked this pull request as ready for review November 27, 2025 17:45
@alexcrocha alexcrocha merged commit f7ae33c into ar-rust-rbs-build Nov 28, 2025
15 of 27 checks passed
alexcrocha added a commit that referenced this pull request Jan 13, 2026
Refactor the previous implementation of `Symbol`/`Keyword` handling to
treat them as first-class nodes in the build configuration.

`Keyword` and `Symbol` represent identifiers (interned strings), not
traditional AST nodes. However, the C parser defines them in
`rbs_node_type` (as `RBS_KEYWORD` and `RBS_AST_SYMBOL`) and treats them
as nodes (`rbs_node_t*`) in many contexts (lists, hashes).

Instead of manually defining `RBSSymbol`/`RBSKeyword` structs, we now
inject them into the `config.yml` node list in `build.rs`. This allows
them to be generated as `SymbolNode`/`KeywordNode` variants in the
`Node` enum, enabling polymorphic handling (in Node lists and Hashes)
alexcrocha added a commit that referenced this pull request Jan 13, 2026
Refactor the previous implementation of `Symbol`/`Keyword` handling to
treat them as first-class nodes in the build configuration.

`Keyword` and `Symbol` represent identifiers (interned strings), not
traditional AST nodes. However, the C parser defines them in
`rbs_node_type` (as `RBS_KEYWORD` and `RBS_AST_SYMBOL`) and treats them
as nodes (`rbs_node_t*`) in many contexts (lists, hashes).

Instead of manually defining `RBSSymbol`/`RBSKeyword` structs, we now
inject them into the `config.yml` node list in `build.rs`. This allows
them to be generated as `SymbolNode`/`KeywordNode` variants in the
`Node` enum, enabling polymorphic handling (in Node lists and Hashes)
alexcrocha added a commit that referenced this pull request Jan 14, 2026
Refactor the previous implementation of `Symbol`/`Keyword` handling to
treat them as first-class nodes in the build configuration.

`Keyword` and `Symbol` represent identifiers (interned strings), not
traditional AST nodes. However, the C parser defines them in
`rbs_node_type` (as `RBS_KEYWORD` and `RBS_AST_SYMBOL`) and treats them
as nodes (`rbs_node_t*`) in many contexts (lists, hashes).

Instead of manually defining `RBSSymbol`/`RBSKeyword` structs, we now
inject them into the `config.yml` node list in `build.rs`. This allows
them to be generated as `SymbolNode`/`KeywordNode` variants in the
`Node` enum, enabling polymorphic handling (in Node lists and Hashes)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants