ICE with unsizing an extern type #79409
Labels
C-bug
Category: This is a bug.
F-extern_types
`#![feature(extern_types)]`
F-unsized_locals
`#![feature(unsized_locals)]`
glacier
ICE tracked in rust-lang/glacier.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
requires-nightly
This issue requires a nightly compiler in some way.
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
DutchGhost
added
C-bug
jonas-schievink
added
F-extern_types
|
It seems clear to me that this shouldn't compile: there's no way to determine, even at run time, how many bytes of storage But this presents a pretty big problem: unsized locals of #![feature(extern_types)]
#![feature(unsized_locals)]
extern {
type Foo;
}
fn mk_foo() -> Box<Foo> {
unimplemented!()
}
fn unsized_local_generic_parameter<T: ?Sized>(x: Box<T>) {
// `unsized_locals` allows you to create locals of generic `?Sized`
// parameter types
let _x = *x;
}
fn main() {
// But `extern_types` allows you to create pointers to extern types, and
// pass them to functions expecting a pointer to a `?Sized` parameter type
unsized_local_generic_parameter(mk_foo());
}It seems to me that these features can't coexist as they are currently - I think this needs discussion from the lang team. |
|
Triage: Still reproduces in Playground on current nightly, now at |
|
matthiaskrgr
added
the
S-bug-has-test
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 12, 2025
Sized Hierarchy This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). 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 migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows: - On the current edition, `Sized` is rewritten as `const Sized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted. - On the next edition, non-const `Sized` will resume being the default bound. - On the current edition, `?Sized` is rewritten as `const MetaSized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted. - On the next edition, writing `?Sized` will be prohibited. - On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already. - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted. - On the next edition, there is no default `const MetaSized` supertrait. Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const 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). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. 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 (library: +573/-184, compiler: +1268/-310, tests: +3720/-452). - It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible. - I'd appreciate feedback on how best to go about this from those familiar with the type system. - On my local machine, this passes all of the test suites, a stage two build and a tidy check. - `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. Fixes rust-lang#79409. r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 17, 2025
Sized Hierarchy This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). 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 migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows: - On the current edition, `Sized` is rewritten as `const Sized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted. - On the next edition, non-const `Sized` will resume being the default bound. - On the current edition, `?Sized` is rewritten as `const MetaSized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted. - On the next edition, writing `?Sized` will be prohibited. - On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already. - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted. - On the next edition, there is no default `const MetaSized` supertrait. Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const 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). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. 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 (library: +573/-184, compiler: +1268/-310, tests: +3720/-452). - It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible. - I'd appreciate feedback on how best to go about this from those familiar with the type system. - On my local machine, this passes all of the test suites, a stage two build and a tidy check. - `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. Fixes rust-lang#79409. r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 18, 2025
Sized Hierarchy This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). 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 migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows: - On the current edition, `Sized` is rewritten as `const Sized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted. - On the next edition, non-const `Sized` will resume being the default bound. - On the current edition, `?Sized` is rewritten as `const MetaSized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted. - On the next edition, writing `?Sized` will be prohibited. - On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already. - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted. - On the next edition, there is no default `const MetaSized` supertrait. Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const 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). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. 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 (library: +573/-184, compiler: +1268/-310, tests: +3720/-452). - It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible. - I'd appreciate feedback on how best to go about this from those familiar with the type system. - On my local machine, this passes all of the test suites, a stage two build and a tidy check. - `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) Fixes rust-lang#79409. r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 18, 2025
Sized Hierarchy This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). 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 migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows: - On the current edition, `Sized` is rewritten as `const Sized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted. - On the next edition, non-const `Sized` will resume being the default bound. - On the current edition, `?Sized` is rewritten as `const MetaSized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted. - On the next edition, writing `?Sized` will be prohibited. - On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already. - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted. - On the next edition, there is no default `const MetaSized` supertrait. Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const 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). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. 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 (library: +573/-184, compiler: +1268/-310, tests: +3720/-452). - It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible. - I'd appreciate feedback on how best to go about this from those familiar with the type system. - On my local machine, this passes all of the test suites, a stage two build and a tidy check. - `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) Fixes rust-lang#79409. r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Mar 24, 2025
Sized Hierarchy This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). 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 migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows: - On the current edition, `Sized` is rewritten as `const Sized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted. - On the next edition, non-const `Sized` will resume being the default bound. - On the current edition, `?Sized` is rewritten as `const MetaSized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted. - On the next edition, writing `?Sized` will be prohibited. - On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already. - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted. - On the next edition, there is no default `const MetaSized` supertrait. Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const 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). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. 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 (library: +573/-184, compiler: +1268/-310, tests: +3720/-452). - It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible. - I'd appreciate feedback on how best to go about this from those familiar with the type system. - On my local machine, this passes all of the test suites, a stage two build and a tidy check. - `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) Fixes rust-lang#79409. r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 10, 2025
Sized Hierarchy This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). 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 migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows: - On the current edition, `Sized` is rewritten as `const Sized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted. - On the next edition, non-const `Sized` will resume being the default bound. - On the current edition, `?Sized` is rewritten as `const MetaSized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted. - On the next edition, writing `?Sized` will be prohibited. - On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already. - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted. - On the next edition, there is no default `const MetaSized` supertrait. Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const 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). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. 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 (library: +573/-184, compiler: +1268/-310, tests: +3720/-452). - It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible. - I'd appreciate feedback on how best to go about this from those familiar with the type system. - On my local machine, this passes all of the test suites, a stage two build and a tidy check. - `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) Fixes rust-lang#79409. r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 11, 2025
Sized Hierarchy This patch implements rust-lang/rfcs#3729. It introduces two new traits to the standard library, `MetaSized` and `PointeeSized`, and makes `MetaSized` and `Sized` into const traits (relying on unstable `feature(const_trait_impl)`). 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 migrations which are necessary to preserve backwards compatibility given the introduction of these traits, which are implemented and as follows: - On the current edition, `Sized` is rewritten as `const Sized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const Sized` will be emitted. - On the next edition, non-const `Sized` will resume being the default bound. - On the current edition, `?Sized` is rewritten as `const MetaSized` - If the `sized_hierarchy` feature is enabled, then an edition migration lint to rewrite the bound to `const MetaSized` will be emitted. - On the next edition, writing `?Sized` will be prohibited. - On the current edition, `const MetaSized` is added as a default supertrait for all traits w/out an explicit sizedness supertrait already. - If the `sized_hierarchy` feature is enabled, then an edition migration lint to add an explicit `const MetaSized` supertrait will be emitted. - On the next edition, there is no default `const MetaSized` supertrait. Each of these migrations is not conditional on whether the item being migrated *needs* the migration to the stricter bound - this would be preferable but is not yet implemented (if it is possible to implement). All diagnostic output should remain the same (showing `?Sized` even if the compiler sees `const 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). Only once `sized_hierarchy` is stabilised would edition migration lints start to be emitted and diagnostic output show the "real" sizedness traits behind-the-scenes, rather than `?Sized`. 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 (library: +573/-184, compiler: +1268/-310, tests: +3720/-452). - It is expected that this will have performance regressions initially and I'll aim to resolve those prior to merging if possible. - I'd appreciate feedback on how best to go about this from those familiar with the type system. - On my local machine, this passes all of the test suites, a stage two build and a tidy check. - `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) Fixes rust-lang#79409. r? `@ghost` (I'll discuss this with relevant teams to find a reviewer)
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 14, 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) Fixes rust-lang#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
Code
Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: