-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
base: master
Are you sure you want to change the base?
Sized Hierarchy: Part I #137944
Conversation
This comment has been minimized.
This comment has been minimized.
|
This comment has been minimized.
This comment has been minimized.
73f1b4f
to
7f509ab
Compare
This comment has been minimized.
This comment has been minimized.
2537bfb
to
b31fd85
Compare
cc @rust-lang/lang |
Does this perhaps fix #127336 by rejecting it? |
This comment was marked as resolved.
This comment was marked as resolved.
b31fd85
to
2beed43
Compare
It doesn't currently. |
2beed43
to
839b844
Compare
Undrafting now that CI passes |
Given the necessary additions of bounds to these traits and their impls in the standard library, it is necessary to add `MetaSized` bounds to the obligation which is proven as part of checking for dyn dispatchability.
Like `Sized` diagnostics, sorting `MetaSized` and `PointeeSized` diagnostics last prevents earlier more useful diagnostics from being skipped because there has already been error tainting.
When printing impl headers in a diagnostic, the compiler has to account for `?Sized` implying `MetaSized` and new `MetaSized` and `PointeeSized` bounds.
When `sized_hierarchy` is enabled, rustc should print `MetaSized` or `PointeeSized` instead of `?Sized` in opaques.
These tests necessarily need to change now that `?Sized` is not sufficient to accept extern types and `PointeeSized` is now necessary. In addition, the `size_of_val`/`align_of_val` test can now be changed to expect an error.
With the addition of new bounds to the unconstrained parameters, there are more errors which just need blessed.
It seems like generics from `non_lifetime_binders` don't have any default bounds like normal generics, so all of the `?Sized` relaxations need to be further relaxed with `PointeeSized` for this test to be the equivalent of before.
This test no longer crashes the compiler as `Box` no longer accepts `PointeeSized`-types. It eventually could, but not because of `Deref::Target` currently, so this doesn't fail anymore and there wasn't an obvious to add new types to make it continue to fail because `Deref` is special.
These tests just need blessing, they don't have any interesting behaviour changes. Some of these tests have new errors because `LegacyReceiver` cannot be proven to be implemented now that it is also testing for `MetaSized` - but this is just a consequence of the other errors in the test.
Extend the fast path for `Sized` traits to include constness and `MetaSized`.
As a performance optimization, skip elaborating the supertraits of `Sized`, and if a `MetaSized` obligation is being checked, then look for a `Sized` predicate in the parameter environment. This makes the `ParamEnv` smaller which should improve compiler performance as it avoids all the iteration over the larger `ParamEnv`.
`nominal_obligations` calls `predicates_of` on a `Sized` obligation, effectively elaborating the trait and making the well-formedness checking machinery do a bunch of extra work checking a `MetaSized` obligation is well-formed, but given that both `Sized` and `MetaSized` are built-ins, if `Sized` is otherwise well-formed, so `MetaSized` will be.
These should never be shown to users at the moment.
Some rustdoc tests are `no_core` and need to have `MetaSized` and `PointeeSized` added to them.
As before, updating types using extern types to use `PointeeSized` bounds.
Unexpected Clippy lint triggering is fixed in upcoming commits but is necessary for `cfg(bootstrap)`.
Existing lints that had special-casing for `Sized` predicates ought to have these same special cases applied to `MetaSized` predicates.
One clippy test is `no_core` and needs to have `MetaSized` and `PointeeSized` added to it.
As in many previous commits, adding the new traits to minicore, but this time for cranelift and gcc.
It's unclear why this change in miri is necessary.
These error messages include lines of the standard library which have changed and so need updated.
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
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)
The job Click to see the possible cause of the failure (guessed by this bot)
|
This patch implements the non-const parts of rust-lang/rfcs#3729. It introduces two new traits to the standard library,
MetaSized
andPointeeSized
. 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 behindcfg
s as this would make implementation unfeasible, there would simply be too manycfg
s required to add the necessary bounds everywhere. So, likeSized
, 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 asMetaSized
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 seesMetaSized
) unless thesized_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:
PointeeSized
is a different name from the RFC just to make it more obvious that it is different fromstd::ptr::Pointee
but all the names are yet to be bikeshed anyway.Fixes #79409.
r? @ghost (I'll discuss this with relevant teams to find a reviewer)