-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-NLLArea: Non-lexical lifetimes (NLL)Area: Non-lexical lifetimes (NLL)C-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.NLL-completeWorking towards the "valid code works" goalWorking towards the "valid code works" goalP-mediumMedium priorityMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
I should have opened this issue a long while ago, but now I have a place in the code I want to link it to.
Match bindings have weird lifetime, especially when guards are involved: instead of the destructors executing when the bindings go out of scope, all of the destructors of all match bindings are run just after the match ends.
e.g. I think this causes unnecessary drop elaboration and etc. load on big functions with many-armed matches.
One very weird case is this:
fn main() {
match 0 {
a | a
if { println!("a={}", a); false } => {}
_ => {}
}
}
Here, the guard is executed twice, and a
is only storage-killed after the match ends, so we have storage-live -> storage-live -> storage-dead, which might annoy some things.
FIXME: remember more weird cases and clean them up.
Metadata
Metadata
Assignees
Labels
A-NLLArea: Non-lexical lifetimes (NLL)Area: Non-lexical lifetimes (NLL)C-cleanupCategory: PRs that clean code up or issues documenting cleanup.Category: PRs that clean code up or issues documenting cleanup.NLL-completeWorking towards the "valid code works" goalWorking towards the "valid code works" goalP-mediumMedium priorityMedium priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.