Inherent const impl

[oli-obk]

Some constifications are annoying because we need to repeat T: Trait bounds from an impl block on the individual constified const fns as T: [const] Trait. We've brainstormed solutions before, and one would be to have separate const impl blocks or sth. However the final syntax will look, I decided to just impl this syntax and either have sth nice on nightly to work with or at least move the discussion along.

Also interacts with the discussion around impl const Trait for Type vs const impl Trait for Type, as we may want to use the latter to keep inherent and trait impls in sync (unless we come up with even another scheme).

• rustdoc + tests
• macro stability /regression tests

r? @fee1-dead

cc @traviscross @rust-lang/project-const-traits

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Changes to the size of AST and/or HIR nodes.

cc @nnethercote

[traviscross]

Looks good to me, including from the side of the lang experiment, as the lang champion.

View changes since this review

[fee1-dead]

I see something asymmetric here, and this is something we might want to address either here or some time later.

We only encode impl methods' constness for trait impls and those are inherited from the impl, but is it not better to just look at the parent and only encode constness once? Since we're going with the whole-trait whole-impl approach anyways.

In the other direction, we should not encode const impl also and have all the assocs encode their constness.

[fee1-dead]

wonder if using ControlFlow here would be more clearer

[fee1-dead]

are we not going to format impl const Tr to const impl Tr? Feels like it should be placed at the earlier places now.

[fee1-dead]

should probably run the span until we reach \n, / (start of a comment), or fn, or any other modifier that occurs after fn, this doesn't seem ideal

[fee1-dead]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: cb034f2 (cb034f2a46aa06b8466754d9310106afca386763, parent: e5efc336720901420a8891dcdb67ca0a475dc03c)

[rust-timer]

Finished benchmarking commit (cb034f2): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

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

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)	-	-	0
Regressions ❌ (secondary)	0.5%	[0.5%, 0.6%]	3
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.0%, secondary -0.7%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.8%	[0.8%, 0.9%]	3
Improvements ✅ (primary)	-1.0%	[-1.0%, -1.0%]	1
Improvements ✅ (secondary)	-5.5%	[-5.5%, -5.5%]	1
All ❌✅ (primary)	-1.0%	[-1.0%, -1.0%]	1

Cycles

Results (secondary 0.2%)

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

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[1.5%, 3.0%]	5
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-5.5%	[-7.6%, -3.3%]	2
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 473.413s -> 473.703s (0.06%)
Artifact size: 390.72 MiB -> 390.78 MiB (0.01%)