Remove unnecessary layout assertions for object-safe receivers #136520
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
|
r? lcnr or reassign as you see fit |
|
sgtm @bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 4, 2025
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#136242 (Remove `LateContext::match_def_path()`) - rust-lang#136274 (Check Sizedness of return type in WF) - rust-lang#136284 (Allow using named consts in pattern types) - rust-lang#136477 (Fix a couple NLL TLS spans ) - rust-lang#136497 (Report generic mismatches when calling bodyless trait functions) - rust-lang#136520 (Remove unnecessary layout assertions for object-safe receivers) - rust-lang#136526 (mir_build: Rename `thir::cx::Cx` to `ThirBuildCx` and remove `UserAnnotatedTyHelpers`) Failed merges: - rust-lang#136304 (Reject negative literals for unsigned or char types in pattern ranges and literals) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Feb 4, 2025
Rollup merge of rust-lang#136520 - compiler-errors:redundant-layout-assert, r=lcnr Remove unnecessary layout assertions for object-safe receivers The soundness of `DispatchFromDyn` relies on the fact that, like all other built-in marker-like layout traits (e.g. `Sized`, `CoerceUnsized`), the guarantees that they enforce in *generic* code via traits will result in assumptions that we can rely on in codegen. Specifically, `DispatchFromDyn` ensures that we end up with a receiver that is a valid pointer type, and its implementation validity recursively ensures that the ABI of that pointer type upholds the `Scalar` or `ScalarPair` representation for sized and unsized pointees, respectively. The check that this layout guarantee holds for arbitrary, possibly generic receiver types that also may exist in possibly impossible-to-instantiate where clauses is overkill IMO, and leads to several ICEs due to the fact that computing layouts before monomorphization is going to be fallible at best. This PR removes the check altogether, since it just exists as a sanity check from very long ago, 6f2a161. Fixes rust-lang#125810 Fixes rust-lang#90110 This PR is an alternative to rust-lang#136195. cc `@adetaylor.` I didn't realize in that PR that the layout checks that were being modified were simply *sanity checks*, rather than being actually necessary for soundness.
|
@rust-timer build 2c194e7 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (2c194e7): 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 the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (secondary 0.0%)This 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.
CyclesResults (secondary -2.2%)This 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: 778.717s -> 777.033s (-0.22%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The soundness of
DispatchFromDynrelies on the fact that, like all other built-in marker-like layout traits (e.g.Sized,CoerceUnsized), the guarantees that they enforce in generic code via traits will result in assumptions that we can rely on in codegen.Specifically,
DispatchFromDynensures that we end up with a receiver that is a valid pointer type, and its implementation validity recursively ensures that the ABI of that pointer type upholds theScalarorScalarPairrepresentation for sized and unsized pointees, respectively.The check that this layout guarantee holds for arbitrary, possibly generic receiver types that also may exist in possibly impossible-to-instantiate where clauses is overkill IMO, and leads to several ICEs due to the fact that computing layouts before monomorphization is going to be fallible at best.
This PR removes the check altogether, since it just exists as a sanity check from very long ago, 6f2a161.
Fixes #125810
Fixes #90110
This PR is an alternative to #136195. cc @adetaylor. I didn't realize in that PR that the layout checks that were being modified were simply sanity checks, rather than being actually necessary for soundness.