-
-
Notifications
You must be signed in to change notification settings - Fork 672
Refactor duplicated code from ASTBase node AliasThis into a mixin template #12796
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.
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
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,18 @@ | ||
| // This file contains mixin templates that define the parse time fields and methods of AST nodes. | ||
| module dmd.astmembers; | ||
|
|
||
| mixin template parseTimePropertiesAliasThis() | ||
| { | ||
| Identifier ident; | ||
|
|
||
| extern (D) this(const ref Loc loc, Identifier ident) | ||
| { | ||
| super(loc, null); // it's anonymous (no identifier) | ||
| this.ident = ident; | ||
| } | ||
|
|
||
| override void accept(Visitor v) | ||
| { | ||
| v.visit(this); | ||
| } | ||
| } |
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't really address the duplication though, does it? There are still two copies of
AliasThispresent, and every time a new AST node is introduced it must still be defined twice.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only way we could eliminate the duplication would be to have the ASTCodegen classes inherit from the ASTBase classes, however, that would require multiple inheritance since a node must inherit its parse time counterpart but also its logical ancestor (for example AddExp would need to inherit ParseTimeAddExp and BinaryExp). This could technically be done by using inheritance and alias this, but I would rather not go there since this currently isn't defined behavior (and ideally alias this would be deprecated for classes).
Instead, this PR limits the scope of the duplication. Indeed, new AST node declarations still need to be duplicated, but I would argue that this doesn't happen very often.
I couldn't come up with a solution that doesn't require to refactor the compiler entirely (e.g. stripping all AST nodes of their functions, basically transforming them into data containers) . If anyone has any propositions, I'm open to suggestions. However, I doubt that a feasible solution to get rid of the duplicated AST node declarations is possible at this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not? We've already removed the semantic, semantic2, semantic3, resolve, toIR, toCtype, toElem, toDt, and probably many more this way.
There are pointless member functions:
dmd/src/dmd/statement.d
Lines 216 to 249 in 0ff19fb
There doesn't need to be a big clear-out done, just anything that isn't to do with examining itself. e.g. from Statement:
dmd/src/dmd/statement.h
Lines 119 to 129 in 0ff19fb
Remove the above highlighted functions, and astbase can just publicly import
dmd.statement...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, it's not that easy. Looking at
statement.dit imports a lot of modules that don't have anything to do with parsing. Before being able to importstatement.dwe need to get rid of all of those dependencies. That is no easy task and it requires a lot of refactorings.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be surprised if it stays that way after dealing with the above functions.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that
statement.dhas many dependencies. Even if we move out everything that relies on semantic information from statement.d, we will still have some Expression fields.expression.dhas other dependencies that rely on semantic information, so now we need to the same for it too etc. My point is that, before we can simply doimport statement;in ASTBase, we need to do this cleanup for all the AST nodes, otherwise the import dependencies are going to drag semantic information into ASTBase.