Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement const expressions and patterns (RFC 2920) #77124

Merged
merged 11 commits into from
Oct 17, 2020

Conversation

spastorino
Copy link
Member

@spastorino spastorino commented Sep 23, 2020

@rust-highfive
Copy link
Collaborator

r? @oli-obk

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 23, 2020
compiler/rustc_ast/src/ast.rs Outdated Show resolved Hide resolved
compiler/rustc_ast/src/ast.rs Outdated Show resolved Hide resolved
@petrochenkov petrochenkov self-assigned this Sep 24, 2020
Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would personally somewhat strongly prefer a different expression name here, for example InlineConst. AnonConst is already in use to describe all unnamed constants (array lengths etc) of which
these expressions are only a subset.

[u8; 3 + 4]
    ^^^^^^
StructFoo<{3 + 7}>
           ^^^^^^

Apart from this I think these changes look good

compiler/rustc_ast/src/ast.rs Outdated Show resolved Hide resolved
src/test/ui/parser/keyword-const-as-identifier.rs Outdated Show resolved Hide resolved
compiler/rustc_parse/src/parser/mod.rs Outdated Show resolved Hide resolved
compiler/rustc_parse/src/parser/mod.rs Show resolved Hide resolved
compiler/rustc_ast_pretty/src/pprust.rs Outdated Show resolved Hide resolved
compiler/rustc_parse/src/parser/stmt.rs Outdated Show resolved Hide resolved
@petrochenkov petrochenkov removed their assignment Sep 24, 2020
@jyn514 jyn514 added A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) F-inline_const Inline constants (aka: const blocks, const expressions, anonymous constants) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 25, 2020
@spastorino spastorino force-pushed the const-exprs-rfc-2920 branch 4 times, most recently from 2ca921d to d56e67b Compare September 29, 2020 02:52
@bors

This comment has been minimized.

@spastorino spastorino force-pushed the const-exprs-rfc-2920 branch 6 times, most recently from 39e8252 to 9af38b0 Compare October 6, 2020 21:52
@bors
Copy link
Contributor

bors commented Oct 17, 2020

⌛ Testing commit 03321b8 with merge 6af9846...

@bors
Copy link
Contributor

bors commented Oct 17, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: oli-obk
Pushing 6af9846 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 17, 2020
@bors bors merged commit 6af9846 into rust-lang:master Oct 17, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 17, 2020
@leonardo-m
Copy link

I've tried:

#![allow(incomplete_features)]
#![feature(inline_const)]
fn main() {
    const N: u32 = 10;
    let x: u32 = 3;

    match x {
        1 .. const { N - 1 } => {},
        _ => {},
    }
}

It gave me errors:

error: expected one of `=>`, `if`, or `|`, found keyword `const`
 --> ...\temp.rs:9:14
  |
9 |         1 .. const { N - 1 } => {},
  |              ^^^^^ expected one of `=>`, `if`, or `|`

error[E0658]: half-open range patterns are unstable
 --> ...\temp.rs:9:9
  |
9 |         1 .. const { N - 1 } => {},
  |         ^^^^
  |
  = note: see issue #67264 <https://github.com/rust-lang/rust/issues/67264> for more information
  = help: add `#![feature(half_open_range_patterns)]` to the crate attributes to enable

@jplatte
Copy link
Contributor

jplatte commented Oct 19, 2020

@leonardo-m You should probably open a new issue about that.

@leonardo-m
Copy link

@leonardo-m You should probably open a new issue about that.

OK, filed as #78108

self.s.word_space("const");
self.s.word("{");
self.print_anon_const(anon_const);
self.s.word("}");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly to AST printing, the expr is already a block, printing the braces again shouldn't be necessary.

@@ -545,6 +546,11 @@ impl<'a> Parser<'a> {
self.check_or_expected(self.token.can_begin_const_arg(), TokenType::Const)
}

fn check_inline_const(&mut self) -> bool {
self.check_keyword(kw::Const)
&& self.look_ahead(1, |t| t == &token::OpenDelim(DelimToken::Brace))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

token::NtBlock should probably also work as a next token.
(At least it will be successfully parsed by parse_const_expr.)

@leonardo-m
Copy link

leonardo-m commented Oct 19, 2020

One use case I've found in my code:

let _m = [const { Vec::<u32>::new() }; 40];

Rustc could suggest to write that when a programmer tries to write:

let _m = [vec![]; 40];

JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 21, 2020
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 21, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Oct 22, 2020
…t, r=petrochenkov

Make inline const work in range patterns

Fixes rust-lang#78108 which is a follow up of rust-lang#77124

r? @petrochenkov
JohnTitor added a commit to JohnTitor/rust that referenced this pull request Oct 23, 2020
…t, r=petrochenkov

Make inline const work in range patterns

Fixes rust-lang#78108 which is a follow up of rust-lang#77124

r? @petrochenkov
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Apr 22, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 22, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 24, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 24, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 24, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 24, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Apr 24, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) F-inline_const Inline constants (aka: const blocks, const expressions, anonymous constants) merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.