-
Notifications
You must be signed in to change notification settings - Fork 13.3k
2229: Mark insignificant dtor in stdlib #89144
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
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 |
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