Raw lifetimes

[compiler-errors]

See rust-lang/rust#126452

[mattheww]

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 .

[ehuss]

Can you update https://doc.rust-lang.org/nightly/reference/tokens.html#reserved-prefixes to include a new rule for the reserved prefix lifetime? I would assume it is something like

`'` (IDENTIFIER_OR_KEYWORD | _) `#`

And update the examples in the "Edition differences" in that section to include reserved lifetime prefixes.

Can you add a "Raw lifetime or label" section similar to https://doc.rust-lang.org/nightly/reference/identifiers.html#raw-identifiers that explains what the raw lifetime means?

Can you add an "Edition differences" block in the "Lifetimes and loop labels" section that explains that raw lifetimes are not supported before 2021? There are some examples within the tokens.md chapter of "Edition differences" blocks for the kind of wording to use.

[ehuss]

@compiler-errors Just checking if you'll be able to look at the requested changes?

[compiler-errors]

I believe I addressed the comments, but please look closely because markdown is not my thing.

[compiler-errors]

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.

[compiler-errors]

@rustbot ready

[ehuss]

I believe this should also include _, right? That is, 'r#_ is valid, correct?

I also just want to double-check, it is intentional that 'r#_ is allowed as a loop label? (I only ask because '_ is explicitly not allowed).

Suggested change

	>    `'r#` [IDENTIFIER_OR_KEYWORD][identifier]
	>       `'r#` [IDENTIFIER_OR_KEYWORD][identifier]
	> _(not immediately followed by `'`)_\
	>    | `'r#_`

[compiler-errors]

Actually this is likely something else we want to deny here. I feel like 'r#_ is invalid, or at least not something we need to support initially.

[ehuss]

rust-lang/rust#132363

Hopefully resolved by 912a6d5

[mattheww]

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; }

[mattheww]

I think this is isn't reserving 'r# on its own, which rustc rejects but could lex as 'r followed by #.

But I'm not sure it's worth trying to get all the RESERVED_ rules exactly right at this stage.

[ehuss]

Posted rust-lang/edition-guide#330 as the companion for the edition.

[ehuss]

@rustbot author

[ehuss]

@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 #1668.

Please let me know if you think the current version looks good.

[ehuss]

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.

[compiler-errors]

LGTM!

[ehuss]

Thanks!