-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Pessimistically assume opaque types are !Freeze #113617
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
let const_qualifs = tcx.mir_const_qualif(def); | ||
|
||
let const_qualifs = match tcx.def_kind(def) { | ||
DefKind::Fn | DefKind::AssocFn | DefKind::Closure | ||
if tcx.constness(def) == hir::Constness::Const | ||
|| tcx.is_const_default_method(def.to_def_id()) => | ||
{ | ||
tcx.mir_const_qualif(def) | ||
} | ||
DefKind::AssocConst | ||
| DefKind::Const | ||
| DefKind::Static(_) | ||
| DefKind::InlineConst | ||
| DefKind::AnonConst => tcx.mir_const_qualif(def), | ||
_ => ConstQualifs::default(), | ||
}; |
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.
This change does not affect any logic and just reduces the number of mir_const_qualif
calls, and thus hopefully also reduces the cost of caching things
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
⌛ Trying commit b39f459 with merge edce3b8a2c0692991244661e01c4b20430e8c3ed... |
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Note that this can break some programs that currently compile on stable, for example: const fn foo() -> impl Sized {}
const _: () = {
let x = foo();
let _ = &x;
core::mem::forget(x)
}; Is this considered acceptable breakage? I guess you do have to go pretty out of your way to write code like that. |
Finished benchmarking commit (edce3b8a2c0692991244661e01c4b20430e8c3ed): comparison URL. Overall result: ✅ improvements - no action neededBenchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf. @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 657.866s -> 658.453s (0.09%) |
closing in favor of #113169 |
Only call `mir_const_qualif` if absolutely necessary Pull the perf change out of rust-lang#113617 This should not have any impact on behaviour (if it does, we'll see an ICE)
Only call `mir_const_qualif` if absolutely necessary Pull the perf change out of rust-lang#113617 This should not have any impact on behaviour (if it does, we'll see an ICE)
…rochenkov Only call `mir_const_qualif` if absolutely necessary Pull the perf change out of rust-lang#113617 This should not have any impact on behaviour (if it does, we'll see an ICE)
Only call `mir_const_qualif` if absolutely necessary Pull the perf change out of rust-lang/rust#113617 This should not have any impact on behaviour (if it does, we'll see an ICE)
fixes #112602
This PR fixes a cycle bug, and thus rely entirely on the body-analysis of the constant, instead of trying to look at the opaque type's hidden type. The main issue is that
const fn
and const items share their analysis, even thoughconst fn
don't care about the resulting qualifications, and only need them within the body to detect currently-illegal things like mutable references or interior mutability behind references. If we pessimistically assume opaque types have interior mutability, we can avoid the cycle errors, but are still respecting the feature gates and soundness.As the tests I added show, we assume that opaque types have interior mutable data, even if the hidden type is a
String
. Note that we have a body-analysis, which shows that forNone
or()
there can be no interior mutability, and thus appear to be looking behind an opaque type, when we are in fact looking at a constant's body.r? lang