-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
2229: Mark insignificant dtor in stdlib #89144
Conversation
src/test/ui/closures/2229_closure_analysis/migrations/insignificant_drop.rs
Show resolved
Hide resolved
It's pretty worrying when something that was rejected as a general purpose language feature is widely employed by a standard library and makes observable difference that cannot (?) be emulated on stable Rust. Or is |
This feature only affects migrations for RFC 2229, so is both largely a quality of life improvement and something we could drop with no impact to stability guarantees (just affects lint's, and ones usually not used). For these reasons I don't find it too concerning that stable Rust can't use this attribute. In practice I believe our expectation is that most crates will find std annotations sufficient to avoid spurious migrations. |
I see, thanks. |
// Since the destructor is insignificant, we just want to make sure all of | ||
// the passed in type parameters are also insignificant. | ||
// Eg: Vec<T> dtor is insignificant when T=i32 but significant when T=Mutex. | ||
return Ok(substs.types().collect::<Vec<Ty<'_>>>().into_iter()); |
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.
@nikomatsakis is probably better to say here, but I think this is actually the wrong thing to check? We probably need to look not at the subst types but at the fields with substs applied -- in particular, for something like the following I suspect this will do the wrong thing right now?
struct Foo<T: Trait> {
var: T::Bar, // T::Bar is significant drop, T is not
}
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.
That said I suspect this won't affect any of the std types... so it might be OK
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.
Exactly-- I agree that it's not necessarily what you would want in the "general case" but in practice I think it's adequate.
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's also not obvious that you want the fields -- for example, in the case of our HashMap that wraps another one, if we looked at the fields, we would flag that as a significant dtor
// Since the destructor is insignificant, we just want to make sure all of | ||
// the passed in type parameters are also insignificant. | ||
// Eg: Vec<T> dtor is insignificant when T=i32 but significant when T=Mutex. | ||
return Ok(substs.types().collect::<Vec<Ty<'_>>>().into_iter()); |
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's also not obvious that you want the fields -- for example, in the case of our HashMap that wraps another one, if we looked at the fields, we would flag that as a significant dtor
r? @nikomatsakis -- I could approve this I think, but ultimately you seem like the better candidate :) Also beta-nominating since I think it's important we have this for the RFC 2229 migrations out of the box, it gets less useful the more people migrate their code. |
@bors r+ p=1 |
📌 Commit 994793f has been approved by |
⌛ Testing commit 994793f with merge d01801521a35e3f4bcd85a0db57ba567c13cdbae... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry macro-document-private-duplicate.rs has been disabled. |
☀️ Test successful - checks-actions |
Finished benchmarking commit (05044c2): comparison url. Summary: This benchmark run did not return any relevant changes. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
2229: Mark insignificant dtor in stdlib I looked at all public [stdlib Drop implementations](https://doc.rust-lang.org/stable/std/ops/trait.Drop.html#implementors) and categorized them into Insigificant/Maybe/Significant Drop. Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501 One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion. r? `@Mark-Simulacrum` cc `@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)
…, r=Amanieu Mark some more types as having insignificant dtor These were caught by rust-lang#129864 (comment), which is implementing a lint for some changes in drop order for temporaries in tail expressions. Specifically, the destructors of `CString` and the bitpacked repr for `std::io::Error` are insignificant insofar as they don't have side-effects on things like locking or synchronization; they just free memory. See some discussion on rust-lang#89144 for what makes a drop impl "significant"
Rollup merge of rust-lang#130914 - compiler-errors:insignificant-dtor, r=Amanieu Mark some more types as having insignificant dtor These were caught by rust-lang#129864 (comment), which is implementing a lint for some changes in drop order for temporaries in tail expressions. Specifically, the destructors of `CString` and the bitpacked repr for `std::io::Error` are insignificant insofar as they don't have side-effects on things like locking or synchronization; they just free memory. See some discussion on rust-lang#89144 for what makes a drop impl "significant"
I looked at all public stdlib Drop implementations and categorized them into Insigificant/Maybe/Significant Drop.
Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501
One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion.
r? @Mark-Simulacrum
cc @nikomatsakis