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.

[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