Sized Hierarchy

[davidtwco]

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 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 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

Fixes #79409.

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

[davidtwco]

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

[traviscross]

cc @rust-lang/lang

[tmiasko]

Does this perhaps fix #127336 by rejecting it?

[davidtwco]

Does this perhaps fix #127336 by rejecting it?

It doesn't currently.

[davidtwco]

Undrafting now that CI passes

[davidtwco]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 121b836 with merge 256c6ac...

[bors]

☀️ Try build successful - checks-actions
Build commit: 256c6ac (256c6acd5363c30574e726976dc3b2d26f15386f)

[davidtwco]

Adding some sizedness special-casing to the fast path for the type_op_prove_predicate query didn't seem to do anything.

[davidtwco]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 845d9fd with merge 8dd4ea2...

[rust-log-analyzer]

A job failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

☀️ Try build successful - checks-actions
Build commit: 8dd4ea2 (8dd4ea2101b7553230e171606d222194a615014c)

[rust-timer]

Finished benchmarking commit (8dd4ea2): comparison URL.

Overall result: ❌ regressions - please read the text below

Benchmarking 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 @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This 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.

	mean	range	count
Regressions ❌ (primary)	2.3%	[0.2%, 14.5%]	231
Regressions ❌ (secondary)	3.3%	[0.1%, 20.2%]	172
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.3%	[0.2%, 14.5%]	231

Max RSS (memory usage)

Results (primary 2.3%, secondary 1.4%)

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.

	mean	range	count
Regressions ❌ (primary)	2.6%	[0.9%, 4.6%]	10
Regressions ❌ (secondary)	4.1%	[2.3%, 6.4%]	9
Improvements ✅ (primary)	-0.6%	[-0.6%, -0.6%]	1
Improvements ✅ (secondary)	-3.6%	[-4.3%, -2.6%]	5
All ❌✅ (primary)	2.3%	[-0.6%, 4.6%]	11

Cycles

Results (primary 4.4%, secondary 6.4%)

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.

	mean	range	count
Regressions ❌ (primary)	4.4%	[1.2%, 13.5%]	100
Regressions ❌ (secondary)	6.4%	[1.6%, 23.0%]	73
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	4.4%	[1.2%, 13.5%]	100

Binary size

Results (primary 0.3%, secondary 0.3%)

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.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.0%, 1.3%]	64
Regressions ❌ (secondary)	0.3%	[0.0%, 0.6%]	31
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.0%, 1.3%]	64

Bootstrap: 776.359s -> 788.732s (1.59%)
Artifact size: 365.12 MiB -> 365.38 MiB (0.07%)

[davidtwco]

CI failure is spurious. After some chatting with @oli-obk, I believe that the performance regression is unrelated to the vast majority of the changes in this patch - a smaller patch just making Sized into a const trait and making Sized bounds (implicit and explicit) into const Sized will have the same regression - it's just adding the host effect predicates that does it. Looking into this.