2229: Mark insignificant dtor in stdlib #89144
Conversation
rust-highfive
added
the
S-waiting-on-review
src/test/ui/closures/2229_closure_analysis/migrations/insignificant_drop.rs
Show resolved
Hide resolved
the8472
added
the
T-libs
|
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.
@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.
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.
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.
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.
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
Mark-Simulacrum
added
beta-nominated
|
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 |
bors
added
S-waiting-on-bors
|
⌛ 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
added
S-waiting-on-review
|
@bors retry macro-document-private-duplicate.rs has been disabled. |
bors
added
S-waiting-on-bors
|
☀️ 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 |
rustbot
added
the
beta-accepted
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`
ehuss
removed
the
beta-nominated
[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)
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