Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 98e05af

Browse files
committedApr 24, 2024·
Auto merge of rust-lang#104087 - nbdd0121:const, r=scottmcm
Stabilise inline_const # 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: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#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. rust-lang#89964). The inference is implemented in rust-lang#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: ```rust 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 rust-lang#96557. This allows code like: ```rust 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: ```rust 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: rust-lang#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
2 parents 5557f8c + 8169c4c commit 98e05af

File tree

95 files changed

+206
-319
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

95 files changed

+206
-319
lines changed
 

‎compiler/rustc_ast_passes/src/feature_gate.rs

-1
Original file line numberDiff line numberDiff line change
@@ -556,7 +556,6 @@ pub fn check_crate(krate: &ast::Crate, sess: &Session, features: &Features) {
556556
half_open_range_patterns_in_slices,
557557
"half-open range patterns in slices are unstable"
558558
);
559-
gate_all!(inline_const, "inline-const is experimental");
560559
gate_all!(inline_const_pat, "inline-const in pattern position is experimental");
561560
gate_all!(associated_const_equality, "associated const equality is incomplete");
562561
gate_all!(yeet_expr, "`do yeet` expression is experimental");

‎compiler/rustc_feature/src/accepted.rs

+2
Original file line numberDiff line numberDiff line change
@@ -211,6 +211,8 @@ declare_features! (
211211
(accepted, inclusive_range_syntax, "1.26.0", Some(28237)),
212212
/// Allows inferring outlives requirements (RFC 2093).
213213
(accepted, infer_outlives_requirements, "1.30.0", Some(44493)),
214+
/// Allow anonymous constants from an inline `const` block
215+
(accepted, inline_const, "CURRENT_RUSTC_VERSION", Some(76001)),
214216
/// Allows irrefutable patterns in `if let` and `while let` statements (RFC 2086).
215217
(accepted, irrefutable_let_patterns, "1.33.0", Some(44495)),
216218
/// Allows `#[instruction_set(_)]` attribute.

0 commit comments

Comments
 (0)
Please sign in to comment.