-
Notifications
You must be signed in to change notification settings - Fork 151
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
Lower IfLet expressions #1218
Lower IfLet expressions #1218
Conversation
Would you like a review @antego or would you still like to do more here? |
Ideally I'd like to make the compilation work. But now I'm not sure since there are possibly too many changes for one PR judging by this #1177 (comment) |
@antego all the steps mentioned in the issue should be done in multiple PRs imo. It's a good idea to have a PR dedicated to lowering, one to name resolution, one to type checking, one to backend compilation etc. |
f583322
to
e125119
Compare
Thanks! I'll create separate PRs. |
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 think that overall this looks good :)
@@ -120,6 +120,39 @@ class ASTLoweringIfBlock : public ASTLoweringBase | |||
bool terminated; | |||
}; | |||
|
|||
class ASTLoweringIfLetBlock : public ASTLoweringBase |
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.
Any reason why you chose to add a new visitor class instead of simply implementing the function in ASTLoweringIfBlock
? It seems you're not using new class members or anything, so it might be simpler to reuse this existing class.
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 reason is because the translated
field in the ASTLoweringIfBlock
is of type HIR::IfExpr
and can't accomodate the HIR::IfLetExpr
.
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.
Then I think it would make more sense to turn that into an HIR::ExprWithBlock *
but @philberty might think your approach is better. I'm honestly fine with both, I just think it's easier for you to not have to reimplement an entire class/visitor :)
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.
Refactoring to use ExprWithBlock might be a really good idea to cleanup the code a bit here but lets do that as a separate piece since it will affect other code we can raise this as a good-first-pr refactor.
Addresses Rust-GCC#1177.
e125119
to
245215b
Compare
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.
LGTM we can do the refactor down the line.
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.
bors r+
Build succeeded: |
This PR addresses #1177. This change implements the "hir-lowering" part of the plan outlined here #1177 (comment).