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

A problem with inline_const feature in ranges #78108

Closed
leonardo-m opened this issue Oct 19, 2020 · 3 comments · Fixed by #78116
Closed

A problem with inline_const feature in ranges #78108

leonardo-m opened this issue Oct 19, 2020 · 3 comments · Fixed by #78116
Assignees
Labels
A-parser Area: The parsing of Rust source code to an AST A-patterns Relating to patterns and pattern matching C-bug Category: This is a bug. 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.

Comments

@leonardo-m
Copy link

As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this:

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

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

That gives 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

So I am not sure if this is a bug report or an enhancement request.

@jyn514 jyn514 added A-const-eval Area: Constant evaluation (MIR interpretation) A-parser Area: The parsing of Rust source code to an AST C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Oct 19, 2020
@camelid camelid added F-inline_const Inline constants (aka: const blocks, const expressions, anonymous constants) and removed A-const-eval Area: Constant evaluation (MIR interpretation) labels Oct 19, 2020
@camelid
Copy link
Member

camelid commented Oct 19, 2020

Note that this does work in expressions (playground):

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

    let range = 1 .. const { N - 1 };
    println!("{:?}", range);
}

@camelid camelid added the A-patterns Relating to patterns and pattern matching label Oct 19, 2020
@camelid camelid self-assigned this Oct 19, 2020
@petrochenkov
Copy link
Contributor

Support for ranges in patterns (1 .. const { 2 } or const { 1 } .. 2) needs to be added separately, to fn parse_pat_range_end and fn parse_pat_with_range_pat respectively.

@spastorino
Copy link
Member

spastorino commented Oct 19, 2020

Ohh I've just realized that we had this issue opened, I've fixed this in #78116.

Going to adjust description of the PR accordingly so it closes this issue when merged.

@camelid camelid assigned spastorino and unassigned camelid Oct 19, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue 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
@bors bors closed this as completed in 982c4b3 Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-parser Area: The parsing of Rust source code to an AST A-patterns Relating to patterns and pattern matching C-bug Category: This is a bug. 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.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants