Introduce const Trait (always-const trait bounds)

[fmease]

Feature const_trait_impl currently lacks a way to express “always const” trait bounds. This makes it impossible to define generic items like fns or structs which contain types that depend on const method calls (*). While the final design and esp. the syntax of effects / keyword generics isn't set in stone, some version of “always const” trait bounds will very likely form a part of it. Further, their implementation is trivial thanks to the effects backbone.

Not sure if this needs t-lang sign-off though.

(*):

#![feature(const_trait_impl, effects, generic_const_exprs)]

fn compute<T: const Trait>() -> Type<{ T::generate() }> { /*…*/ }

struct Store<T: const Trait>
where
    Type<{ T::generate() }>:,
{
    field: Type<{ T::generate() }>,
}

Lastly, “always const” trait bounds are a perfect fit for generic_const_items.

#![feature(const_trait_impl, effects, generic_const_items)]

const DEFAULT<T: const Default>: T = T::default();

Previously, we (oli, fee1-dead and I) wanted to reinterpret ~const Trait as const Trait in generic const items which would've been quite surprising and not very generalizable.
Supersedes #117530.

---

cc @oli-obk

As discussed
r? fee1-dead (or compiler)

[fmease]

I've moved this {Node,Hir}Id creation below the HirId registration for the hir::ExprKind::Path above to accommodate the control flow, I hope that doesn't break any invariants (?).

[compiler-errors]

No, as long as you didn't move it outside of a nested self.with_* function.

[compiler-errors]

Actually... hm... it's probably fine...

[compiler-errors]

Do we have tests to check that we deny ~const in const items and structs and stuff?

[fmease]

Do we have tests to check that we deny ~const in const items and structs and stuff?

Yes, we do: https://github.com/rust-lang/rust/blob/master/tests/ui/rfcs/rfc-2632-const-trait-impl/tilde-const-invalid-places.rs

[fmease]

I need to investigate if this visibly changes the MBE matching behavior for stable users. I hope not since this check is required for correctness.

[fmease]

Doesn't seem to be a problem. I've added a test to ensure that const Trait doesn't regress stable code: tests/ui/rfcs/rfc-2632-const-trait-impl/mbe-bare-trait-objects-const-trait-bounds.rs

[fmease]

It's obvious in hindsight but this doesn't regress the aforementioned test because I haven't (and I won't) add kw::Const & TokenKind::Tilde to can_begin_type.

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

[bors]

☔ The latest upstream changes (presumably #119163) made this pull request unmergeable. Please resolve the merge conflicts.

[fee1-dead]

I did not see an ui test for the padding suggestion. Could you give me a link to it or add it?

[fmease]

Well, padding didn't actually make sense. I've removed it. I could run-rustfix for the -Zparse-only test tests/ui/parser/bounds-type.rs but I'm not sure if it's worth it esp. since it concerns a maybe-incorrect suggestion.

No need for run-rustfix, just an ui test that would have covered this code path with stderr would be fine. Though removing it also works.

It's a tool-only suggestion atm, hence it doesn't show up on stderr.

Network error
@bors retry

⌛ Testing commit 3eb48a3 with merge 88d69b7...

☀️ Test successful - checks-actions
Approved by: fee1-dead
Pushing 88d69b7 to master...

Finished benchmarking commit (88d69b7): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

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

Max RSS (memory usage)

Results

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.1%, 0.5%]	2
Regressions ❌ (secondary)	0.9%	[0.9%, 0.9%]	2
Improvements ✅ (primary)	-0.8%	[-0.8%, -0.8%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.0%	[-0.8%, 0.5%]	3

Cycles

Results

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.6%	[0.5%, 0.8%]	3
Regressions ❌ (secondary)	1.1%	[1.1%, 1.1%]	1
Improvements ✅ (primary)	-0.5%	[-0.5%, -0.5%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-0.5%, 0.8%]	4

Binary size

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

Bootstrap: 670.98s -> 672.366s (0.21%)
Artifact size: 312.28 MiB -> 312.33 MiB (0.02%)

@fmease @compiler-errors @fee1-dead I'm hoping I can get some help. I've bisected rust-lang/rustfmt#6035 back to this PR.

With the following input: m!(const N: usize = 0;);

rustfmt 1.7.0-dev (88d69b7 2023-12-27) outputs:

m!(const N: usize = 0;);

but the commit just before (rustfmt 1.7.0-dev (a861c89 2023-12-27)) outputs:

m!(
    const N: usize = 0;
);

Any idea why the formatting would have changed?