Skip to content
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

Merged
merged 4 commits into from
Sep 25, 2021

Conversation

wesleywiser
Copy link
Member

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

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
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 23, 2021
@rust-log-analyzer

This comment has been minimized.

let a = (HasDrop, HasDrop);
let b = (HasDrop, HasDrop);

let c = #[rustc_capture_analysis]
Copy link
Member

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.

Copy link
Member Author

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).

compiler/rustc_typeck/src/check/upvar.rs Show resolved Hide resolved
@wesleywiser wesleywiser changed the title Rfc 2229 droporder [rfc 2229] Drop fully captured upvars in the same order as the regular drop code Sep 24, 2021
@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Sep 24, 2021

📌 Commit 3893656 has been approved by nikomatsakis

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 24, 2021
Manishearth added a commit to Manishearth/rust that referenced this pull request Sep 24, 2021
…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`
@nbdd0121
Copy link
Contributor

Should this be backported to beta?

@wesleywiser
Copy link
Member Author

Added some comments to existing tests, clarified which notes are important in the preserve_field_drop_order test and added some new test cases in preserve_field_drop_order2.

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Sep 24, 2021

📌 Commit dd91804 has been approved by nikomatsakis

@wesleywiser
Copy link
Member Author

Should this be backported to beta?

Yes, I believe we want this to ship with the 2021 edition.

@wesleywiser wesleywiser added the beta-nominated Nominated for backporting to the compiler in the beta channel. label Sep 24, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Sep 25, 2021
…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
@bors bors merged commit 7ade6ed into rust-lang:master Sep 25, 2021
@rustbot rustbot added this to the 1.57.0 milestone Sep 25, 2021
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Sep 30, 2021
@apiraino
Copy link
Contributor

Beta backport accepted as per compiler team on Zulip

@rustbot label +beta-accepted

@rustbot rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label Sep 30, 2021
ehuss pushed a commit to ehuss/rust that referenced this pull request Oct 4, 2021
…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`
@ehuss ehuss mentioned this pull request Oct 4, 2021
@ehuss ehuss removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label Oct 4, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 4, 2021
[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)
@Mark-Simulacrum Mark-Simulacrum modified the milestones: 1.57.0, 1.56.0 Oct 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
beta-accepted Accepted for backporting to the compiler in the beta channel. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Drop order affected because of use order