Unterminated char literal complains about lifetimes

[estebank]

Given the following code

let _ = ['1','2,'3'];

the current output is

error: lifetimes cannot start with a number
 --> src/main.rs:2:18
  |
2 |     let _ = ['1','2,'3'];
  |                  ^^

error: expected `while`, `for`, `loop` or `{` after a label
 --> src/main.rs:2:20
  |
2 |     let _ = ['1','2,'3'];
  |                    ^ expected `while`, `for`, `loop` or `{` after a label

It should instead recognize that a char literal was intended:

error: unterminated char literal
 --> src/main.rs:2:18
  |
2 |     let _ = ['1','2,'3'];
  |                  ^^
help: add a closing `'`
  |
2 |     let _ = ['1','2','3'];
  |                    +

https://internals.rust-lang.org/t/error-message-for-vec-1-2-3/17309

[steffahn]

Note that users might deliberately try naming lifetimes '1 or '2, too, in other cases; especially given that some error messages introduce lifetimes with such stand-in names, e.g.

[snip]
3 | fn f(x: Cell<(&i32, &i32)>) {
  |               -     - let's call the lifetime of this reference `'1`
  |               |
  |               let's call the lifetime of this reference `'2`
4 |     g(x)
  |     ^^^^ argument requires that `'1` must outlive `'2`

[estebank]

Yes, the error recovery should be constricted to places where a char literal would be completely valid.

[compiler-errors]

I think we can do this with a stashed diagnostic.

[estebank]

I think a limited lookahead (and maybe some passed down info) that checks whether a literal is acceptable there.

[ChayimFriedman2]

Are they even accepted in the same positions? Lifetimes are only in generic parameter lists and chars are only in expressions, no?

Edit: Oh, but labels.

[compiler-errors]

Lifetimes can also be labels that start blocks

[ChayimFriedman2]

So "if not followed by colon" can be a pretty good estimation. We can also restrict even more to "colon then brace or loop or while or for".