FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

use simpler GrmtoolsSectionValue throughout by ratmice · Pull Request #666 · softdevteam/grmtools · GitHub

use simpler GrmtoolsSectionValue throughout - #666

Open
ratmice wants to merge 4 commits into
softdevteam:masterfrom
ratmice:grmtools_section_value
Open

use simpler GrmtoolsSectionValue throughout#666
ratmice wants to merge 4 commits into
softdevteam:masterfrom
ratmice:grmtools_section_value

Conversation

ratmice commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

This is an experiment to see if we can do away with Value<T> and all it's friends Setting, Namespaced, etc.
Replacing it with the much simpler GrmtoolsSectionValue<T>. This can lead to slightly worse error messages.
e.g. because we're checking YaccKind as a whole including YaccOriginalActionKind. But I think it is pretty much limited to that. We could perhaps do better, by attempting to parse the RustLike(string) rather than the simple matching I've done here.

Sadly this patch has ended up kind of redoing some of the case-insensitivity migration in #665
This came up because when experimenting with integrading the lookup methods with the used value checking.
This involved changing the value owned by the GrammarAST from a HashMap<GrmtoolsSectionValue> to the Header<T>. Then the lookup methods would have to clone the value and return an owned GrmtoolsSectionValue, because there was none to borrow anymore.

It feels like this solves that borrowing issue, but also is a much simpler structure, and so cleans up the code a lot?

impl<'input> GrmtoolsSectionParser<'input> {
fn parse_setting(&'_ self, mut i: usize) -> Result<(Setting<Span>, usize), HeaderError<Span>> {
fn parse_setting(
&'_ self,

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Just noticing that now a few of the functions like parse_setting and parse_namespaced which
historically made sense since they previously returned Setting and Namespaced probably need better names like parse_rustlike for parse_namespaced..

Alas I don't have a good idea for parse_setting, which is to the right hand side of the : in value: setting.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I renamed these parse_value and parse_rustlike in e882220 and a80866d

Comment thread lrpar/src/lib/parser.rs Outdated
member: ("None".to_string(), from_loc.clone()),
})),
RecoveryKind::CPCTPlus => {
GrmtoolsSectionValue::RustLike("RecoveryKind::CPCTPlus".to_string(), from_loc)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I think these can probably be simplified by using the ToTokens/implementations to produce the string
rather than these hard coded values.

Ditto for elsewhere.

ratmice Aug 29, 2026
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

Alas, that doesn't seem to work (it emits a fully qualified path like :: lrpar :: RecoveryKind :: CPCTPlus)

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

The best I could come up with to simplify these further was using Debug 3129318

ratmice marked this pull request as ready for review August 29, 2026 06:01
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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants


Back | FazBrowse Home | New Git URL