-
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
Explain revealing of opaque types in layout_of ParamEnv #115762
Conversation
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
@@ -324,6 +324,7 @@ impl<'tcx> SizeSkeleton<'tcx> { | |||
param_env: ty::ParamEnv<'tcx>, | |||
) -> Result<SizeSkeleton<'tcx>, &'tcx LayoutError<'tcx>> { | |||
debug_assert!(!ty.has_non_region_infer()); | |||
let param_env = param_env.with_reveal_all_normalized(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.
Ok yeah, this preserves the revealing behavior of size computation. I think that's why more tests don't explode, makes sense.
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.
yea, I had lots of tests explode, and didn't look too deeply, but assumed I could write a stable test that would break
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Avoid revealing in layout_of r? `@compiler-errors` I feel like `layout_of` is doing too many things at once, and I don't really know why. It could allow us to if callers could decide whether to reveal opaque types.
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (ec12977): comparison URL. Overall result: ❌✅ regressions and improvements - 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @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: 629.503s -> 632.559s (0.49%) |
Need to bless tests @rustbot author |
21e8d63
to
f316e44
Compare
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
hmm... looks like we got a lot more I'll open a separate PR to try out the const eval trick on |
Nevermind, that change isn't possible without also doing this PR, so trying it out here @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Avoid revealing in layout_of r? `@compiler-errors` I feel like `layout_of` is doing too many things at once, and I don't really know why. It could allow us to if callers could decide whether to reveal opaque types.
This comment has been minimized.
This comment has been minimized.
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (e9ce6f9): comparison URL. Overall result: ❌✅ regressions and improvements - 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 633.305s -> 636.592s (0.52%) |
I guess there's nothing to be done here. This is an optimization, so my original reasoning about there being no reason for it is wrong |
28bfd7a
to
ee59531
Compare
@bors r+ |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#109409 (Add `minmax{,_by,_by_key}` functions to `core::cmp`) - rust-lang#115494 (get rid of duplicate primitive_docs) - rust-lang#115663 (ci: actions/checkout@v3 to actions/checkout@v4) - rust-lang#115762 (Explain revealing of opaque types in layout_of ParamEnv) - rust-lang#115891 (simplify inject_impl_of_structural_trait) - rust-lang#115932 (Expand infra-ci reviewer list) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#109409 (Add `minmax{,_by,_by_key}` functions to `core::cmp`) - rust-lang#115494 (get rid of duplicate primitive_docs) - rust-lang#115663 (ci: actions/checkout@v3 to actions/checkout@v4) - rust-lang#115762 (Explain revealing of opaque types in layout_of ParamEnv) - rust-lang#115891 (simplify inject_impl_of_structural_trait) - rust-lang#115932 (Expand infra-ci reviewer list) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#115762 - oli-obk:early_const_prop_lint2, r=compiler-errors Explain revealing of opaque types in layout_of ParamEnv r? `@compiler-errors` ~~I feel like `layout_of` is doing too many things at once, and I don't really know why. It could allow us to if callers could decide whether to reveal opaque types.~~ Looks like this also exists as a performance optimization. While we could probably figure out a way to do this, all the ones I came up with are fragile as `layout_of` callers now suddenly need to be careful what ParamEnv they pass in.
r? @compiler-errors
I feel likelayout_of
is doing too many things at once, and I don't really know why. It could allow us to if callers could decide whether to reveal opaque types.Looks like this also exists as a performance optimization. While we could probably figure out a way to do this, all the ones I came up with are fragile as
layout_of
callers now suddenly need to be careful what ParamEnv they pass in.