-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Smaller and more correct generator codegen #69814
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
This didn't cause issues before since generator types were always considered to "need drop", leading to unwind paths (including a `Resume` block) always getting generated.
The indices do not matter here, and this fixes an index out of bounds panic when compiling a generator that can unwind but not return.
Co-Authored-By: bjorn3 <bjorn3@users.noreply.github.com>
You should be able to write a test that generators can't be resumed once unwound (covering the case fixed here). |
Hmm, not sure how I'd do that. Besides a call to
|
1, | ||
(POISONED, insert_panic_block(tcx, body, ResumedAfterPanic(generator_kind))), | ||
); | ||
} |
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.
Maybe swap the order of insert
s here so the same ordering is kept.
|
||
if can_return { | ||
cases.insert( | ||
1, |
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.
If can_unwind
and can_return
, this will overwrite the POISONED
case.
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.
insert
on a Vec
can't overwrite.
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.
It should be moved to index 2 though, right?
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.
Ah, missed that reply
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 thought cases
was an FxHashMap
.
@bors r+ |
📌 Commit 38fa378 has been approved by |
I'm currently looking into making |
Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind, respectively. Closes rust-lang#66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it, ultimately reaching a `Resume` terminator, which we already handled correctly. Future MIR optimizations might optimize that out, though. r? @Zoxc
Smaller and more correct generator codegen This removes unnecessary panicking branches in the resume function when the generator can not return or unwind, respectively. Closes rust-lang#66100 It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation *inside* a generator that could possibly unwind will result in a cleanup path for dropping it, ultimately reaching a `Resume` terminator, which we already handled correctly. Future MIR optimizations might optimize that out, though. r? @Zoxc
Rollup of 9 pull requests Successful merges: - #69036 (rustc: don't resolve Instances which would produce malformed shims.) - #69443 (tidy: Better license checks.) - #69814 (Smaller and more correct generator codegen) - #69929 (Regenerate tables for Unicode 13.0.0) - #69959 (std: Don't abort process when printing panics in tests) - #69969 (unix: Set a guard page at the end of signal stacks) - #70005 ([rustdoc] Improve visibility for code blocks warnings) - #70088 (Use copy bound in atomic operations to generate simpler MIR) - #70095 (Implement -Zlink-native-libraries) Failed merges: r? @ghost
Rollup of 9 pull requests Successful merges: - #68941 (Properly handle Spans that reference imported SourceFiles) - #69036 (rustc: don't resolve Instances which would produce malformed shims.) - #69443 (tidy: Better license checks.) - #69814 (Smaller and more correct generator codegen) - #69929 (Regenerate tables for Unicode 13.0.0) - #69959 (std: Don't abort process when printing panics in tests) - #69969 (unix: Set a guard page at the end of signal stacks) - #70005 ([rustdoc] Improve visibility for code blocks warnings) - #70088 (Use copy bound in atomic operations to generate simpler MIR) Failed merges: r? @ghost
…atthewjasper Make `needs_drop` less pessimistic on generators Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does. This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications. ~~This builds off of rust-lang#69814 since that contains some fixes that are made relevant by *this* PR (see rust-lang#69814 (comment) (this has been merged)
…atthewjasper Make `needs_drop` less pessimistic on generators Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does. This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications. ~~This builds off of rust-lang#69814 since that contains some fixes that are made relevant by *this* PR (see rust-lang#69814 (comment) (this has been merged)
…atthewjasper Make `needs_drop` less pessimistic on generators Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does. This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications. ~~This builds off of rust-lang#69814 since that contains some fixes that are made relevant by *this* PR (see rust-lang#69814 (comment) (this has been merged)
…atthewjasper Make `needs_drop` less pessimistic on generators Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does. This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications. ~~This builds off of rust-lang#69814 since that contains some fixes that are made relevant by *this* PR (see rust-lang#69814 (comment) (this has been merged)
…atthewjasper Make `needs_drop` less pessimistic on generators Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does. This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications. ~~This builds off of rust-lang#69814 since that contains some fixes that are made relevant by *this* PR (see rust-lang#69814 (comment) (this has been merged)
…thewjasper Make `needs_drop` less pessimistic on generators Generators only have non-trivial drop logic when they may store (in upvars or across yields) a type that does. This prevents generation of some unnecessary MIR in simple generators. There might be some impact on compile times, but this is probably limited in real-world applications. ~~This builds off of rust-lang#69814 since that contains some fixes that are made relevant by *this* PR (see rust-lang#69814 (comment) (this has been merged)
This removes unnecessary panicking branches in the resume function when the generator can not return or unwind, respectively.
Closes #66100
It also addresses the correctness concerns wrt poisoning on unwind. These are not currently a soundness issue because any operation inside a generator that could possibly unwind will result in a cleanup path for dropping it, ultimately reaching a
Resume
terminator, which we already handled correctly. Future MIR optimizations might optimize that out, though.r? @Zoxc