reference
reference copied to clipboard
rust-lang
Raw lifetimes
The
(not immediately followed by
')
bit is there in LIFETIME_OR_LABEL as a way to say that 'xxx'yyy is rejected (rather than being interpreted as two lifetimes).
But (after rust-lang/rust#126452) 'r#xxx'yyy is interpreted as two lifetimes. So I think that bit should be left out of the RAW_LIFETIME rule.
(There's no need to say anything special to indicate that 'r#kw' is rejected: that's true because ' on its own isn't a token, and character literals can't have more than one character between the quotes.)
Alternatively, it might be worth considering changing the implementation to reject 'r#xxx'yyy for consistency with the non-raw case.
Note that allowing that form would close the door to delaying the rejection of overlong character literals to post-expansion, which was being considered late last year at rust-lang/rust#118699 .
@compiler-errors Just checking if you'll be able to look at the requested changes?
I believe I addressed the comments, but please look closely because markdown is not my thing.
Well, except for:
Alternatively, it might be worth considering changing the implementation to reject 'r#xxx'yyy for consistency with the non-raw case.
Which I think I will open a rustc PR to implement.
Do we need changes outside the Lexical structure chapter?
As far as I can see nothing is saying that r#a and 'a are treated as equivalent when used as a lifetime or label.
That is, I don't think the Reference is saying that these are now accepted:
fn foo<'r#a>(s: &'a str) {}
'r#a: { break 'a; }
Posted https://github.com/rust-lang/edition-guide/pull/330 as the companion for the edition.
@compiler-errors I pushed a change for the validation, and also rebased since we made a slight change in the definition of the lifetime token in https://github.com/rust-lang/reference/pull/1668.
Please let me know if you think the current version looks good.
I pushed a commit specifying that 'r#_ will generate an error (and similarly for r#_).
This is a bit of an awkward issue around whether or not _ is an identifier. Currently the reference does not define it that way (intentionally), even though internally rustc allows that (but quickly rejects it). IIRC, there are some issues around that and proc-macros, but I did not look into that.
I did not want to define an identifier token that allowed _, because then I would have to define separate identifier tokens that exclude it, and this _ identifier would only be used by these raw tokens.