-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Abort control flow upon a return
, RET
, or RVRT
.
#964
Conversation
test/src/e2e_vm_tests/test_programs/abort_control_flow/Forc.toml
Outdated
Show resolved
Hide resolved
LGTM otherwise. |
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.
Merge conflicts. Could you move the testcase into the directory structure of #965?
I've tested locally and can confirm that old-compiler does not compile the testcase and new-compiler does.
test/src/e2e_vm_tests/test_programs/should_fail/abort_control_flow/Forc.toml
Outdated
Show resolved
Hide resolved
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, will defer to the actual compiler devs.
This should unblock the final hard blocker for swayswap.
What does this do?
In Rust, if a branch aborts control flow, then its return type doesn't matter. Here is an example.
We want this behavior so we can implement
.unwrap()
-- panicking if there is no value present in anOption
requires that we don't type check theelse
branch in case of a deterministic abort.How does this do?
This PR introduces a
.deterministically_aborts()
method on AST nodes, expressions, and code blocks which returns a true if, in its control flow, there is aRVRT
,RET
, orreturn
that is impossible to avoid. We then special case some type checking in branched code around that, as well as take it into consideration when type checking expressions against their annotations.Other things
While implementing this, I found a bug in
return
statement type checking -- we were not type checking returns that are on the RHS of a variable declaration. For example, the below compiles when it should not.This PR includes a fix for that.
Closes #308