Restrict TUPLE_INDEX to only allow decimal digits

[matthewhughes934]

I was rather confused after reading the current definition and trying out some code:

struct Foo(u32);

fn main() {
    let f = Foo(1);
    let _ = f.0;    // ok
    let _ = f.0_0   // DEC_LTIERAL: error[E0609]: no field `0_0` on type `Foo`
    let _ = f.0b0;  // BIN_LITERAL: error[E0609]: no field `0b0` on type `Foo`
    let _ = f.0o0;  // OCT_LTERAL:  error[E0609]: no field `0o0` on type `Foo`
    let _ = f.0x0;  // HEX_LITERAL: error[E0609]: no field `0x0` on type `Foo`
}

[matthewhughes934]

I thought it was about as much effort to raise a PR with this change as to raise an issue explaining the problem. Though I'm aware the contributing guide asks for opening issues in these cases, so sorry if I've jumped the gun.

[DanielEScherzer]

community review: makes sense to me, given the following rule (bolding added)

r[lex.token.literal.int.tuple-field.eq]
Tuple indices are compared with the literal token directly. Tuple indices start with 0 and each successive index increments the value by 1 as a decimal value. Thus, only decimal values will match, and the value must not have any extra 0 prefix characters.

View changes since this review

[DanielEScherzer]

Some discussion during T-lang-docs office hours - the tuple indexing isn't done as its own grammar rule in the actual compiler, field access is for both named fields and tuple fields

Either the current reference syntax is too permissive (as explained by the author), or it is too restrictive (since things like (5, true).test are accepted fine by the grammar and only rejected later, so they work as inputs to macros)

I think as a reader I would prefer that the reference not suggest things that will be unconditionally rejected in a later pass just because they would be allowed by the actual grammar, but that is just me - either way, the current syntax is incorrect

[DanielEScherzer]

I thought it was about as much effort to raise a PR with this change as to raise an issue explaining the problem. Though I'm aware the contributing guide asks for opening issues in these cases, so sorry if I've jumped the gun.

Your change is something I'm in agreement with, so I'm kind of championing it at the lang docs meetings, hope that is okay with you

[traviscross]

Thanks @matthewhughes934 for taking the time to open this PR. The Reference documents the preexpansion grammar. I.e.:

struct S(u8);

#[cfg(false)]
fn f() {
    let f = S(1);
    let _ = f.0; // OK.
    let _ = f.0_0; // DEC_LTIERAL: OK.
    let _ = f.0b0; // BIN_LITERAL: OK
    let _ = f.0o0; // OCT_LTERAL:  OK.
    let _ = f.0x0; // HEX_LITERAL: OK.
}

That the Reference documents the preexpansion grammar is indeed often a point of confusion. We're thinking about ways in which to make that more clear across the document. But since this change would not be correct due to that, I'm going to close this PR.

[DanielEScherzer]

I've sent #2360 to better document this