-
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
Implement if let
expressions and associated fixes
#815
Conversation
if let
expressionsif let
expressions and associated fixes
} => { | ||
// sorry | ||
let leaked_ix: &'static str = Box::leak(Box::new(elem_to_access_num.to_string())); | ||
let access_ident = Ident::new_with_override(leaked_ix, elem_to_access_span.clone()); |
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.
Obviously less than ideal. Should we make an issue to not need 'static
strings for Ident
?
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'm not sure. I was debating the performance costs. We clone Ident
a lot throughout the compiler. I somewhat suspect that this leak is better for performance than using String
everywhere for Ident
. And using a scoped lifetime, like <'sc>
, would be what we had before and nobody liked that.
This only happens specifically in these tuple accesses. I'm sure we can sort out a more localized solution that just updates the tuple access stuff. Maybe that's what the issue should be about.
test/src/e2e_vm_tests/test_programs/chained_if_let_missing_branch/Forc.toml
Outdated
Show resolved
Hide resolved
Yikes, are we going to get |
All of the I think this is a unique case where the conflicts are potentially related to generating and committing lock files between #825 landing and #876 landing. I probably should have done #876 as a part of #825 to avoid this happening, but that PR was already massive enough! I would probably address this via a rebase onto master, but I know many prefer to avoid rebase and everyone has their own git wrangling strats :) |
test/src/e2e_vm_tests/test_programs/enum_destructuring/Forc.toml
Outdated
Show resolved
Hide resolved
Do not merge until 0.6.1 is released #921 |
Why?
As we don't have any form of destructuring, getting values out of enums is impossible. This hinders our progress in developing the standard library and basic demos -- primarily SwaySwap.
What?
This PR implements
if let
for enums, although not to complete parity with Rust's pattern matching. Some general fixes around generic types/enums/etc., are included in this PR as well.List O' Changes
return
statements inside of if
expressions were not being type checked correctly. This PR fixes that.if let
expressions, which compare an enum's tag and conditionally pull out its contents into a variable.
afer
7. Improved dead code detection such that publicly exported enums don't warn that their variants are unused. 8. Allow type annotations for enum instantiations, i.e. `let x = Result::Ok::(5u64)`Remaining work
impl
blocks and trait interactions are still not there. This PR was big enough as is, so that'll be coming later.if let
only allows for destructuring the top-level enum. This is okay:if let Result::Ok(val) = foo { .. }
, this is not okay:if let Result::Ok(Option::Some(Enum::Variant(x, y, Struct { field, .. } ) ) ) = foo { .. }
closes #817
closes #624