Stabilise inline_const

[nbdd0121]

Stabilisation Report

Summary

This PR will stabilise inline_const feature in expression position. inline_const_pat is still unstable and will not be stabilised.

The feature will allow code like this:

foo(const { 1 + 1 })

which is roughly desugared into

struct Foo;
impl Foo {
    const FOO: i32 = 1 + 1;
}
foo(Foo::FOO)

This feature is from rust-lang/rfcs#2920 and is tracked in #76001 (the tracking issue should not be closed as it needs to track inline const in pattern position). The initial implementation is done in #77124.

Difference from RFC

There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content within it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. #89964). The inference is implemented in #89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body.

This allows code like:

let v: Vec<i32> = const { Vec::new() };

Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in #96557.

This allows code like:

fn create_none_array<T, const N: usize>() -> [Option<T>; N] {
    [const { None::<T> }; N]
}

This enhancement also makes inline const usable as static asserts:

fn require_zst<T>() {
    const { assert!(std::mem::size_of::<T>() == 0) }
}

Documentation

Reference: rust-lang/reference#1295

Unresolved issues

We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation:

• expr fragment specifier issue: Non-terminals, e.g. expr, have diverged between parser and macro matcher #86730
• const {} behaves similar to async {} but not to {} and unsafe {} (they are treated as ExpressionWithoutBlock rather than ExpressionWithBlock): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453

Tests

There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const

[rustbot]

r? @JohnTitor

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[JohnTitor]

I think this needs FCP, cc @rust-lang/lang

[nbdd0121]

@rustbot label: -T-libs +T-lang +I-lang-nominated

[scottmcm]

Thanks for the report! It looks like the current state is enough to allow this to work:

pub fn create_none_array<T, const N: usize>() -> [Option<T>; N] {
    [const { None }; N]
}

which is the use that keeps coming up on URLO. And this also keeps coming up (1 2) on IRLO as needed (or at least wanted) for various things.

So let's do it!

@rfcbot fcp merge

cc Tracking Issue #76001, which also covers patterns so isn't closed by this PR.

[scottmcm]

(Sorry, compiler folks. One day I'll remember to check the labels before kicking off an FCP.)

[rust-timer]

Finished benchmarking commit (7bb4f08): 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)

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

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
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.0%	[-2.0%, -2.0%]	1
Improvements ✅ (secondary)	-2.9%	[-3.3%, -2.5%]	3
All ❌✅ (primary)	-2.0%	[-2.0%, -2.0%]	1

Binary size

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

Bootstrap: 674.062s -> 672.117s (-0.29%)
Artifact size: 316.12 MiB -> 316.14 MiB (0.01%)

[nbdd0121]

@rustbot label +relnotes