-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
[rfc 2229] Drop fully captured upvars in the same order as the regular drop code #89208
Conversation
Currently, with the new 2021 edition, if a closure captures all of the fields of an upvar, we'll drop those fields in the order they are used within the closure instead of the normal drop order (the definition order of the fields in the type). This changes that so we sort the captured fields by the definition order which causes them to drop in that same order as well. Fixes rust-lang/project-rfc-2229#42
This comment has been minimized.
This comment has been minimized.
src/test/ui/closures/2229_closure_analysis/preserve_field_drop_order2.rs
Show resolved
Hide resolved
let a = (HasDrop, HasDrop); | ||
let b = (HasDrop, HasDrop); | ||
|
||
let c = #[rustc_capture_analysis] |
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.
My concern with this test is that we need to reply on checking the stderr, and I feel like if the fields order does get changed, we won't need to update the annoatations in this file and someone might ignore the stderr changes because the ouput needed is all there.
I think we should go with testing with stdout here because changes to stdout are observable behaviour to the user and might be more cause of concern in case something breaks 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.
I think it's useful to check both the internal results via #[rustc_capture_analysis]
as well as the runtime results which is what these two tests do in combination. However, I totally agree with your point that as it is, it would be pretty easy for someone to change this test without realizing what parts are important and which parts aren't. I believe I can remove the checking for the notes we do not care about which should make it much more clear (this is the convention used in other ui tests as well).
@bors r+ |
📌 Commit 3893656 has been approved by |
…ikomatsakis [rfc 2229] Drop fully captured upvars in the same order as the regular drop code Currently, with the new 2021 edition, if a closure captures all of the fields of an upvar, we'll drop those fields in the order they are used within the closure instead of the normal drop order (the definition order of the fields in the type). This changes that so we sort the captured fields by the definition order which causes them to drop in that same order as well. Fixes rust-lang/project-rfc-2229#42 r? `@nikomatsakis`
Should this be backported to beta? |
Added some comments to existing tests, clarified which notes are important in the @bors r=nikomatsakis |
📌 Commit dd91804 has been approved by |
Yes, I believe we want this to ship with the 2021 edition. |
…ingjubilee Rollup of 8 pull requests Successful merges: - rust-lang#88893 (Add 1.56.0 release notes) - rust-lang#89001 (Be explicit about using Binder::dummy) - rust-lang#89072 (Avoid a couple of Symbol::as_str calls in cg_llvm ) - rust-lang#89104 (Simplify scoped_thread) - rust-lang#89208 ([rfc 2229] Drop fully captured upvars in the same order as the regular drop code) - rust-lang#89210 (Add missing time complexities to linked_list.rs) - rust-lang#89217 (Enable "generate-link-to-definition" option on rust tools docs as well) - rust-lang#89221 (Give better error for `macro_rules! name!`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…ikomatsakis [rfc 2229] Drop fully captured upvars in the same order as the regular drop code Currently, with the new 2021 edition, if a closure captures all of the fields of an upvar, we'll drop those fields in the order they are used within the closure instead of the normal drop order (the definition order of the fields in the type). This changes that so we sort the captured fields by the definition order which causes them to drop in that same order as well. Fixes rust-lang/project-rfc-2229#42 r? `@nikomatsakis`
[beta] Beta rollup * Fix WinUWP std compilation errors due to I/O safety rust-lang#88587 * Disable RemoveZsts in generators to avoid query cycles rust-lang#88979 * Disable the evaluation cache when in intercrate mode rust-lang#88994 * Fix linting when trailing macro expands to a trailing semi rust-lang#88996 * Don't use projection cache or candidate cache in intercrate mode rust-lang#89125 * 2229: Mark insignificant dtor in stdlib rust-lang#89144 * Temporarily rename int_roundings functions to avoid conflicts rust-lang#89184 * [rfc 2229] Drop fully captured upvars in the same order as the regular drop code rust-lang#89208 * Use the correct edition for syntax highlighting doctests rust-lang#89277 * Don't normalize opaque types with escaping late-bound regions rust-lang#89285 * Update Let's Encrypt ROOT CA certificate in dist-(i686|x86_64)-linux docker images rust-lang#89486 Cargo update: * - [beta] 1.56 backports (rust-lang/cargo#9958) * - [beta] Revert "When a dependency does not have a version, git or path… (rust-lang/cargo#9912) * - [beta] Fix rustc --profile=dev unstable check. (rust-lang/cargo#9901)
Currently, with the new 2021 edition, if a closure captures all of the
fields of an upvar, we'll drop those fields in the order they are used
within the closure instead of the normal drop order (the definition
order of the fields in the type).
This changes that so we sort the captured fields by the definition order
which causes them to drop in that same order as well.
Fixes rust-lang/project-rfc-2229#42
r? @nikomatsakis