Say that ... range patterns are rejected in the 2021 edition

[mattheww]

Corresponding issue is #1071

[bjorn3]

Can you clarify that before the 2021 edition ..= is also allowed?

[mattheww]

I've reworded in b83fcc1

[ehuss]

Thanks for the PR!

The _ObsoleteRangePattern_ grammar needs to have some kind of indication that it is for < 2021 editions. The grammar blocks are intended to be standalone for the purpose of parsing (text in the English prose is intended for things done after parsing). There isn't much precedent for how that should be formatted. The only things currently are the footnotes in the functions grammar. I think it would be fine to do something similar here. It's a bit awkward to define multiple languages simultaneously.

[mattheww]

I've added a footnote.

I'm not sure anything currently defines whether this rule is considered to be part of the grammar or something that happens after parsing: I don't know a way to make rustc distinguish these cases.

As far as the implementation is concerned, ... isn't rejected when parsing, but by a lint that runs over the generated AST.

I see rust-lang/wg-grammar#6 and rust-lang/wg-grammar#41 have been left unsettled.

Out of interest, I checked what syn does, and it unconditionally accepts both ... and ..= without distinguishing them in the returned AST. It doesn't seem to contemplate parsing varying by edition.

[ehuss]

I'm sorry, I misremembered how that was implemented. I went ahead and removed the last commit, since I was mistaken about how this works. I was thinking this was done in the parser.

From a language perspective, you can test how parsing works via macros, or using false #[cfg] attributes. For example, the following are some examples that work in 2021:

macro_rules! pat {
    ($e:pat) => {};
}

#[cfg(FALSE)]
fn f(x: i32) {
    match x {
        1...2 => {}
    }
}

fn main() {
    pat!(1...2);
}

The idea for the grammar in the reference is to capture what ends up in the AST, which is relevant to macros and expansion.

As for how this is actually implemented, the key part is here where the lint is defined with FutureIncompatibilityReason::EditionError. The majority of lints are handled after expansion.