-
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
Const drop #88558
Const drop #88558
Conversation
This comment has been minimized.
This comment has been minimized.
can we desugar ~const Drop to an auto-trait bound for ConstDrop which we then properly define for everything that needs it, but never expose it to users? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
8ec3353
to
ad926e2
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
891f84e
to
11045cd
Compare
This comment has been minimized.
This comment has been minimized.
29661bd
to
28ef0d6
Compare
This could be problematic. struct NotDrop(String) // has drop glue, but no Drop impl
trait MyTrait {}
impl<T: Drop> MyTrait for T {}
impl MyTrait for NotDrop {} works on stable and can be very useful for some pin related code (source: rust-lang/rfcs#2632 (comment)). |
nonono. I did not make |
In fact I see this as a justification for explicit opt-in over implicit & opt-out. We have |
☔ The latest upstream changes (presumably #80522) made this pull request unmergeable. Please resolve the merge conflicts. |
Finished benchmarking commit (cdeba02): comparison url. Summary: This change led to large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
/// The weird return type of this function allows it to be used with the `try` (`?`) | ||
/// operator within certain functions. | ||
fn check_recursion_limit<T: Display + TypeFoldable<'tcx>, V: Display + TypeFoldable<'tcx>>( | ||
fn check_recursion_depth<T: Display + TypeFoldable<'tcx>>( |
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.
infcx is very sensitive to changes in hot code paths, maybe this change caused it? Can you do a PR without this change (duplicating for your use case) and see how it goes? Or maybe just inline(always) check_recursion_limit?
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.
Let me open a pr adding inline(always) and see how that goes. I don't think anything other than this code caused the regression
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.
Opened #88962.
Okay, I looked through the perf results, and there seems to be a regression for Invoking the trait system is probably really slow... |
const IS_CLEARED_ON_MOVE: bool = true; | ||
|
||
fn in_qualifs(qualifs: &ConstQualifs) -> bool { | ||
qualifs.needs_drop | ||
} | ||
|
||
fn in_any_value_of_ty(cx: &ConstCx<'_, 'tcx>, ty: Ty<'tcx>) -> bool { | ||
ty.needs_drop(cx.tcx, cx.param_env) |
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.
maybe keep this for a fast reject?
inline(always) on check_recursion_limit r? `@oli-obk` rust-lang#88558 caused a regression, this PR adds `#[inline(always)]` to `check_recursion_limit`, a possible suspect of that regression.
Fast reject for NeedsNonConstDrop Hopefully fixes the regression in rust-lang#88558. I've always wanted to help with the performance of rustc, but it doesn't feel the same when you are fixing a regression caused by your own PR... r? `@oli-obk`
Changes from rust-lang#88558 allowed using `~const Drop` in constants by introducing a new `NeedsNonConstDrop` qualif. The new qualif was also used for promotion purposes, and allowed promotion to happen for values that needs to be dropped but which do have a const drop impl. Since for promoted the drop implementation is never executed, this lead to observable change in behaviour. For example: ```rust struct Panic(); impl const Drop for Panic { fn drop(&mut self) { panic!(); } } fn main() { let _ = &Panic(); } ``` Restore the use of `NeedsDrop` qualif during promotion to avoid the issue.
…-obk Do not promote values with const drop that need to be dropped Changes from rust-lang#88558 allowed using `~const Drop` in constants by introducing a new `NeedsNonConstDrop` qualif. The new qualif was also used for promotion purposes, and allowed promotion to happen for values that needs to be dropped but which do have a const drop impl. Since for promoted the drop implementation is never executed, this lead to observable change in behaviour. For example: ```rust struct Panic(); impl const Drop for Panic { fn drop(&mut self) { panic!(); } } fn main() { let _ = &Panic(); } ``` Restore the use of `NeedsDrop` qualif during promotion to avoid the issue.
…fee1-dead Check `const Drop` impls considering `~const` Bounds This PR adds logic to trait selection to account for `~const` bounds in custom `impl const Drop` for types, elaborates the `const Drop` check in `rustc_const_eval` to check those bounds, and steals some drop linting fixes from rust-lang#92922, thanks `@DrMeepster.` r? `@fee1-dead` `@oli-obk` <sup>(edit: guess I can't request review from two people, lol)</sup> since each of you wrote and reviewed rust-lang#88558, respectively. Since the logic here is more complicated than what existed, it's possible that this is a perf regression. But it works correctly with tests, and that makes me happy. Fixes rust-lang#92881
The changes are pretty primitive at this point. But at least it works. ^-^
Problems with the current change that I can think of now:
~const Drop
shouldn't change anything in the non-const world.~const Drop
in const contexts.struct S { a: u8, b: u16 }
This might not fail forneeds_non_const_drop
, but it will fail inrustc_trait_selection
.const Drop
impls but have non-constDrop
glue.Fixes #88424.
Significant Changes:
~const Drop
is no longer treated as a normal trait bound. In non-const contexts, this bound has no effect, but in const contexts, this restricts the input type and all of its transitive fields to either a) have aconst Drop
impl or b) can be trivially dropped (i.e. no drop glue)T: ~const Drop
will not be linted likeT: Drop
.rustc_mir::transform::check_consts
, we use the trait system to special case~const Drop
. Seerustc_trait_selection::...::candidate_assembly#assemble_const_drop_candidates
and others.Changes not related to
const Drop
ping and/or changes that are insignificant:Node.constness_for_typeck
no longer returnshir::Constness::Const
for type aliases in traits. This was previously used to hack how we determine default bound constness for items. But because we now use an explicit opt-in, it is no longer needed.is_const_impl_raw
query. We haveimpl_constness
, and the only existing use of that query usesHirId
, which means we can just operate it with hir.ty::Destructor
now has a fieldconstness
, which represents the constness of the destructor.r? @oli-obk