Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Un-inline the enums in the CST #698

Merged
merged 3 commits into from
Dec 8, 2023
+7,147 −7,137
Merged

Un-inline the enums in the CST #698

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c4c2f4a
Un-inline the enums in the CST
Xanewok Dec 6, 2023
998d3cc
Re-generate files
Xanewok Dec 8, 2023
5329d30
Fix cst-cursor.ts
Xanewok Dec 6, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 1 addition & 2 deletions crates/solidity/inputs/language/src/grammar.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -327,8 +327,7 @@ fn resolve_grammar_element(ident: &Identifier, ctx: &mut ResolveCtx<'_>) -> Gram
let thunk = Rc::new(NamedParserThunk {
name: ident.to_string().leak(),
context: lex_ctx,
// Enums have a single reference per variant, so they should be inlined.
is_inline: matches!(elem.as_ref(), Item::Enum { .. }),
is_inline: false,
Copy link
Contributor

@OmarTawfik OmarTawfik Dec 6, 2023 •
edited
Loading

Choose a reason for hiding this comment

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

I would like to get @AntonyBlakey's eyes on this one. Some of these nodes look very useful, for example ContractMember and ConstructorAttribute, as it makes it easier to find/match on these elements.

However, some of them look extraneous indeed, and are only there for purpose of authoring the grammar/versioning. For example:

  • ElementaryType and YulLiteral which will (almost) always have a unique parent that can be matched against. Maybe we can refactor the grammar a bit to make this more accurate?

  • TypedTupleMember and UntypedTupleMember which only exist to make parsing/backtracking correct, but provide no additional meaning. Not sure how to avoid it.

I’m trying to avoid adding optional inlining to the DSL unless we absolutely need it. As based on all of our new design decisions, and AST structure, it will make it less obvious to go from grammar to CST/AST, and add another layer of complexity that users have to deal with ..

Without inlining, people can easily depend on the fact that any NonTerminal node is convertible to its matching AST type, and vice versa. If we start to have some inlined enums, it won’t be obvious which CST nodes can be converted to AST types directly. And vice versa, it will be confusing if some AST types started returning a root node that have a different NonTerminalKind.

So, if we are happy with these changes, I’m fine with merging the PR as-is for now, and I can manually go over the enums to see if any of them can be better structured. For example, inlining something like ElementaryType variants into the types it references, since it is almost always used inside another Enum. It will probably be more nuanced than that though.

What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

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

Enums that are artefacts of the grammar machinations are not of interest to the CST or the AST. We should I think find a better way to achieve whatever they accomplish. Although I am concerned about the 'almost' comment, because that seems to imply that the constraint is not a logical necessity, and so it must be surfaced as a parent + child.

Copy link
Contributor

Choose a reason for hiding this comment

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

Could we make the non-interesting enum into something else in the grammar i.e. effectively add a non-outlined characteristic by using a different name for the concept. It sure sounds like it has a different purpose.

Copy link
Contributor

Choose a reason for hiding this comment

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

f2f: we think the PR is good enough for now, and let's review the added kinds later to see if anything can be pruned/removed.

def: OnceCell::new(),
});
ctx.resolved.insert(
Expand Down
68 changes: 68 additions & 0 deletions crates/solidity/outputs/cargo/crate/src/generated/kinds.rs
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading