Skip to content

Sized Hierarchy: Part I #137944

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

Merged
merged 30 commits into from
Jun 17, 2025
Merged

Sized Hierarchy: Part I #137944

merged 30 commits into from
Jun 17, 2025

Conversation

davidtwco
Copy link
Member

@davidtwco davidtwco commented Mar 3, 2025

This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, MetaSized and PointeeSized. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to feature(sized_hierarchy). These traits are not behind cfgs as this would make implementation unfeasible, there would simply be too many cfgs required to add the necessary bounds everywhere. So, like Sized, these traits are automatically implemented by the compiler.

RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

  • ?Sized is rewritten as MetaSized
  • MetaSized is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.

There are no edition migrations implemented in this, as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing ?Sized even if the compiler sees MetaSized) unless the sized_hierarchy feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax Deref::Target (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

Notes:

  • Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
  • This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
    • Each commit has a short description describing its purpose.
    • This patch is large but it's primarily in the test suite.
  • I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
  • PointeeSized is a different name from the RFC just to make it more obvious that it is different from std::ptr::Pointee but all the names are yet to be bikeshed anyway.
  • @nikomatsakis has confirmed that this can proceed as an experiment from the t-lang side
  • FCP in Sized Hierarchy: Part I #137944 (comment)

Fixes #79409.

r? @ghost (I'll discuss this with relevant teams to find a reviewer)

@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-json Area: Rustdoc JSON backend A-rustdoc-search Area: Rustdoc's search feature PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) labels Mar 3, 2025
@rust-log-analyzer

This comment has been minimized.

@davidtwco
Copy link
Member Author

davidtwco commented Mar 3, 2025

I can reproduce this locally but I have no idea why it would be related to this patch. Clippy needed adjusting.

@rustbot rustbot added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Mar 3, 2025
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@traviscross traviscross added the T-lang Relevant to the language team label Mar 4, 2025
@traviscross
Copy link
Contributor

cc @rust-lang/lang

@fee1-dead fee1-dead self-assigned this Mar 4, 2025
@tmiasko
Copy link
Contributor

tmiasko commented Mar 4, 2025

Does this perhaps fix #127336 by rejecting it?

@bors

This comment was marked as resolved.

@davidtwco
Copy link
Member Author

Does this perhaps fix #127336 by rejecting it?

It doesn't currently.

@davidtwco
Copy link
Member Author

Undrafting now that CI passes

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (86d0aef): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

  • If the regression was expected or you think it can be justified,
    please write a comment with sufficient written justification, and add
    @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
  • If you think that you know of a way to resolve the regression, try to create
    a new PR with a fix for the regression.
  • If you do not understand the regression or you think that it is just noise,
    you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
    were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

mean range count
Regressions ❌
(primary)
1.3% [0.1%, 9.9%] 111
Regressions ❌
(secondary)
0.9% [0.2%, 2.9%] 101
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.7% [-0.7%, -0.7%] 1
All ❌✅ (primary) 1.3% [0.1%, 9.9%] 111

Max RSS (memory usage)

Results (primary 2.0%, secondary -0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.6% [1.1%, 4.9%] 6
Regressions ❌
(secondary)
2.6% [1.0%, 3.9%] 4
Improvements ✅
(primary)
-1.3% [-1.3%, -1.3%] 1
Improvements ✅
(secondary)
-5.2% [-8.3%, -2.1%] 2
All ❌✅ (primary) 2.0% [-1.3%, 4.9%] 7

Cycles

Results (primary 2.6%, secondary 2.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
2.6% [0.7%, 5.7%] 27
Regressions ❌
(secondary)
2.0% [1.3%, 3.1%] 13
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 2.6% [0.7%, 5.7%] 27

Binary size

Results (primary 0.0%, secondary 0.0%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.0%] 28
Regressions ❌
(secondary)
0.0% [0.0%, 0.0%] 16
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.0% [0.0%, 0.0%] 28

Bootstrap: 756.784s -> 693.274s (-8.39%)
Artifact size: 372.10 MiB -> 372.01 MiB (-0.02%)

@Kobzol
Copy link
Contributor

Kobzol commented Jun 17, 2025

(Note: the bootstrap change is unrelated to this PR, we used to unnecessarily compile too much stuff in the bootstrap benchmark).

github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Jun 18, 2025
Sized Hierarchy: Part I

This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.

There are no edition migrations implemented in this,  as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in rust-lang/rust#137944 (comment)

Fixes rust-lang/rust#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
lnicola pushed a commit to lnicola/rust-analyzer that referenced this pull request Jun 18, 2025
Sized Hierarchy: Part I

This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.

There are no edition migrations implemented in this,  as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in rust-lang/rust#137944 (comment)

Fixes rust-lang/rust#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
davidtwco added a commit to davidtwco/rust that referenced this pull request Jun 18, 2025
During review of rust-lang#137944, we thought we could remove the
builtin impl of `PointeeSized` as it was removed during lowering, but
users can still write `dyn PointeeSized` and so we need the builtin impl.
tautschnig added a commit to tautschnig/kani that referenced this pull request Jun 18, 2025
Relevant upstream PR: rust-lang/rust#137944
(Sized Hierarchy: Part I). This PR implements a part of
[RFC 3729](rust-lang/rfcs#3729), which
prescribes a hierarchy of `Sized` traits. Notably, this disallows
instantiation of `size_of_val` and `align_of_val` with extern types.
Consequently, the code in test `unsized_foreign.rs` no longer compiles
instead of panicking, as it previously did. This test is therefore
removed.

Work in progress: figure out whether we can make `foreign_type.rs` work.

Resolves: model-checking#4165
bjorn3 pushed a commit to rust-lang/rustc_codegen_cranelift that referenced this pull request Jun 19, 2025
Sized Hierarchy: Part I

This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.

There are no edition migrations implemented in this,  as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in rust-lang/rust#137944 (comment)

Fixes rust-lang/rust#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
github-merge-queue bot pushed a commit to model-checking/kani that referenced this pull request Jun 23, 2025
Relevant upstream PR: rust-lang/rust#137944
(Sized Hierarchy: Part I). This PR implements a part of [RFC
3729](rust-lang/rfcs#3729), which prescribes a
hierarchy of `Sized` traits. Notably, this disallows instantiation of
`size_of_val` and `align_of_val` with extern types. Consequently, the
code in tests `unsized_foreign.rs` and `foreign_type.rs`no longer
compiles (when previously some of the tests would panic). These test
were therefore removed.

Resolves: #4165

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
github-merge-queue bot pushed a commit to model-checking/kani that referenced this pull request Jun 23, 2025
Relevant upstream PR: rust-lang/rust#137944
(Sized Hierarchy: Part I). This PR implements a part of [RFC
3729](rust-lang/rfcs#3729), which prescribes a
hierarchy of `Sized` traits. Notably, this disallows instantiation of
`size_of_val` and `align_of_val` with extern types. Consequently, the
code in tests `unsized_foreign.rs` and `foreign_type.rs`no longer
compiles (when previously some of the tests would panic). These test
were therefore removed.

Resolves: #4165

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
github-merge-queue bot pushed a commit to model-checking/kani that referenced this pull request Jun 24, 2025
Relevant upstream PR: rust-lang/rust#137944
(Sized Hierarchy: Part I). This PR implements a part of [RFC
3729](rust-lang/rfcs#3729), which prescribes a
hierarchy of `Sized` traits. Notably, this disallows instantiation of
`size_of_val` and `align_of_val` with extern types. Consequently, the
code in tests `unsized_foreign.rs` as well as parts of `foreign_type.rs`
no longer compile (when previously some of the tests would panic). These
test were therefore removed.

Resolves: #4165

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
@rylev
Copy link
Member

rylev commented Jun 24, 2025

As noted in this summary comment, the performance regression is expected and will be addressed in follow ups.

@rustbot label: +perf-regression-triaged

@rustbot rustbot added the perf-regression-triaged The performance regression has been triaged. label Jun 24, 2025
github-actions bot pushed a commit to tautschnig/verify-rust-std that referenced this pull request Jun 24, 2025
Sized Hierarchy: Part I

This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.

There are no edition migrations implemented in this,  as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in rust-lang#137944 (comment)

Fixes rust-lang#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Jun 26, 2025
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Jun 27, 2025
…r=lcnr

add #![rustc_no_implicit_bounds]

Follow-up from rust-lang#137944.

Adds a new `rustc_attrs` attribute that stops rustc from adding any default bounds. Useful for tests where default bounds just add noise and make debugging harder.

After reviewing all tests with `?Sized`, these tests seem like they could probably benefit from `#![rustc_no_implicit_bounds]`.

- Skipping most of `tests/ui/unsized` as these seem to want to test `?Sized`
- Skipping tests that used `Box<T>` because it's still bound by `T: MetaSized`
- Skipping parsing or other tests that cared about `?Sized` syntactically
- Skipping tests for `derive(CoercePointee)` because this appears to check that the pointee type is relaxed with `?Sized` explicitly

r? `@lcnr`
rust-timer added a commit that referenced this pull request Jun 27, 2025
Rollup merge of #142671 - davidtwco:no-default-bounds-attr, r=lcnr

add #![rustc_no_implicit_bounds]

Follow-up from #137944.

Adds a new `rustc_attrs` attribute that stops rustc from adding any default bounds. Useful for tests where default bounds just add noise and make debugging harder.

After reviewing all tests with `?Sized`, these tests seem like they could probably benefit from `#![rustc_no_implicit_bounds]`.

- Skipping most of `tests/ui/unsized` as these seem to want to test `?Sized`
- Skipping tests that used `Box<T>` because it's still bound by `T: MetaSized`
- Skipping parsing or other tests that cared about `?Sized` syntactically
- Skipping tests for `derive(CoercePointee)` because this appears to check that the pointee type is relaxed with `?Sized` explicitly

r? `@lcnr`
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request Jun 28, 2025
add #![rustc_no_implicit_bounds]

Follow-up from rust-lang/rust#137944.

Adds a new `rustc_attrs` attribute that stops rustc from adding any default bounds. Useful for tests where default bounds just add noise and make debugging harder.

After reviewing all tests with `?Sized`, these tests seem like they could probably benefit from `#![rustc_no_implicit_bounds]`.

- Skipping most of `tests/ui/unsized` as these seem to want to test `?Sized`
- Skipping tests that used `Box<T>` because it's still bound by `T: MetaSized`
- Skipping parsing or other tests that cared about `?Sized` syntactically
- Skipping tests for `derive(CoercePointee)` because this appears to check that the pointee type is relaxed with `?Sized` explicitly

r? `@lcnr`
antoyo pushed a commit to rust-lang/rustc_codegen_gcc that referenced this pull request Jun 28, 2025
Sized Hierarchy: Part I

This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`. See the RFC for the rationale behind these traits and to discuss whether this change makes sense in the abstract.

These traits are unstable (as is their constness), so users cannot refer to them without opting-in to `feature(sized_hierarchy)`. These traits are not behind `cfg`s as this would make implementation unfeasible, there would simply be too many `cfg`s required to add the necessary bounds everywhere. So, like `Sized`, these traits are automatically implemented by the compiler.

RFC 3729 describes changes which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows:

- `?Sized` is rewritten as `MetaSized`
- `MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already.

There are no edition migrations implemented in this,  as these are primarily required for the constness parts of the RFC and prior to stabilisation of this (and so will come in follow-up PRs alongside the const parts). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `MetaSized`) unless the `sized_hierarchy` feature is enabled.

Due to the use of unstable extern types in the standard library and rustc, some bounds in both projects have had to be relaxed already - this is unfortunate but unavoidable so that these extern types can continue to be used where they were before. Performing these relaxations in the standard library and rustc are desirable longer-term anyway, but some bounds are not as relaxed as they ideally would be due to the inability to relax `Deref::Target` (this will be investigated separately).

It is hoped that this is implemented such that it could be merged and these traits could exist "under the hood" without that being observable to the user (other than in any performance impact this has on the compiler, etc). Some details might leak through due to the standard library relaxations, but this has not been observed in test output.

**Notes:**

- Any commits starting with "upstream:" can be ignored, as these correspond to other upstream PRs that this is based on which have yet to be merged.
- This best reviewed commit-by-commit. I've attempted to make the implementation easy to follow and keep similar changes and test output updates together.
  - Each commit has a short description describing its purpose.
  - This patch is large but it's primarily in the test suite.
- I've worked on the performance of this patch and a few optimisations are implemented so that the performance impact is neutral-to-minor.
- `PointeeSized` is a different name from the RFC just to make it more obvious that it is different from `std::ptr::Pointee` but all the names are yet to be bikeshed anyway.
- `@nikomatsakis` has confirmed [that this can proceed as an experiment from the t-lang side](https://rust-lang.zulipchat.com/#narrow/channel/435869-project-goals/topic/SVE.20and.20SME.20on.20AArch64.20.28goals.23270.29/near/506196491)
- FCP in rust-lang/rust#137944 (comment)

Fixes rust-lang/rust#79409.

r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
-Clink-dead-code Linkage option: -Clink-dead-code A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-json Area: Rustdoc JSON backend A-rustdoc-search Area: Rustdoc's search feature A-test-infra-minicore Area: `minicore` test auxiliary and `//@ add-core-stubs` A-testsuite Area: The testsuite used to check the correctness of rustc disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. F-autodiff `#![feature(autodiff)]` finished-final-comment-period The final comment period is finished for this PR / Issue. merged-by-bors This PR was explicitly merged by bors. perf-regression Performance regression. perf-regression-triaged The performance regression has been triaged. PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. T-types Relevant to the types team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ICE with unsizing an extern type