-
Notifications
You must be signed in to change notification settings - Fork 489
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raw lifetimes #1603
base: master
Are you sure you want to change the base?
Raw lifetimes #1603
Conversation
The
bit is there in But (after rust-lang/rust#126452) (There's no need to say anything special to indicate that Alternatively, it might be worth considering changing the implementation to reject 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 . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
@compiler-errors Just checking if you'll be able to look at the requested changes? |
e718896
to
0b6ce17
Compare
I believe I addressed the comments, but please look closely because markdown is not my thing. |
Well, except for:
Which I think I will open a rustc PR to implement. |
@rustbot ready |
src/tokens.md
Outdated
> | RAW_LIFETIME | ||
> | ||
> RAW_LIFETIME :\ | ||
> `'r#` [IDENTIFIER_OR_KEYWORD][identifier] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
> `'r#` [IDENTIFIER_OR_KEYWORD][identifier] | |
> `'r#` [IDENTIFIER_OR_KEYWORD][identifier] | |
> _(not immediately followed by `'`)_\ | |
> | `'r#_` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hopefully resolved by 912a6d5
Do we need changes outside the Lexical structure chapter? As far as I can see nothing is saying that 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; } |
@@ -851,7 +866,8 @@ r[lex.token.reserved-prefix.syntax] | |||
> **<sup>Lexer 2021+</sup>**\ | |||
> RESERVED_TOKEN_DOUBLE_QUOTE : ( IDENTIFIER_OR_KEYWORD <sub>_Except `b` or `c` or `r` or `br` or `cr`_</sub> | `_` ) `"`\ | |||
> RESERVED_TOKEN_SINGLE_QUOTE : ( IDENTIFIER_OR_KEYWORD <sub>_Except `b`_</sub> | `_` ) `'`\ | |||
> RESERVED_TOKEN_POUND : ( IDENTIFIER_OR_KEYWORD <sub>_Except `r` or `br` or `cr`_</sub> | `_` ) `#` | |||
> RESERVED_TOKEN_POUND : ( IDENTIFIER_OR_KEYWORD <sub>_Except `r` or `br` or `cr`_</sub> | `_` ) `#`\ | |||
> RESERVED_TOKEN_LIFETIME : `'` (IDENTIFIER_OR_KEYWORD <sub>_Except `r`_</sub> | _) `#` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Posted rust-lang/edition-guide#330 as the companion for the edition. |
…r=chenyukang Reject raw lifetime followed by `'`, like regular lifetimes do See comment. We want to reject cases like `'r#long'id`, which currently gets interpreted as a raw lifetime (`'r#long`) followed by a lifetime (`'id`). This could have alternative lexes, such as an overlong char literal (`'r#long'`) followed by an identifier (`id`). To avoid committing to this in any case, let's reject the whole thing. `@mattheww,` is this what you were looking for in rust-lang/reference#1603 (comment)? I'd say ignore the details about the specific error message (the fact that this gets reinterpreted as a char literal is 🤷), just that because this causes a lexer error we're effectively saving syntactical space like you wanted.
@rustbot author |
…r=chenyukang Reject raw lifetime followed by `'`, like regular lifetimes do See comment. We want to reject cases like `'r#long'id`, which currently gets interpreted as a raw lifetime (`'r#long`) followed by a lifetime (`'id`). This could have alternative lexes, such as an overlong char literal (`'r#long'`) followed by an identifier (`id`). To avoid committing to this in any case, let's reject the whole thing. `@mattheww,` is this what you were looking for in rust-lang/reference#1603 (comment)? I'd say ignore the details about the specific error message (the fact that this gets reinterpreted as a char literal is 🤷), just that because this causes a lexer error we're effectively saving syntactical space like you wanted.
…=wesleywiser Enforce that raw lifetimes must be valid raw identifiers Make sure that the identifier part of a raw lifetime is a valid raw identifier. This precludes `'r#_` and all module segment paths for now. I don't believe this is compelling to support. This was raised by `@ehuss` in rust-lang/reference#1603 (comment) (well, specifically the `'r#_` case), but I don't see why we shouldn't just make it consistent with raw identifiers.
Rollup merge of rust-lang#132363 - compiler-errors:raw-lt-id-valid, r=wesleywiser Enforce that raw lifetimes must be valid raw identifiers Make sure that the identifier part of a raw lifetime is a valid raw identifier. This precludes `'r#_` and all module segment paths for now. I don't believe this is compelling to support. This was raised by `@ehuss` in rust-lang/reference#1603 (comment) (well, specifically the `'r#_` case), but I don't see why we shouldn't just make it consistent with raw identifiers.
Rollup merge of rust-lang#132341 - compiler-errors:raw-lt-prefix-id, r=chenyukang Reject raw lifetime followed by `'`, like regular lifetimes do See comment. We want to reject cases like `'r#long'id`, which currently gets interpreted as a raw lifetime (`'r#long`) followed by a lifetime (`'id`). This could have alternative lexes, such as an overlong char literal (`'r#long'`) followed by an identifier (`id`). To avoid committing to this in any case, let's reject the whole thing. `@mattheww,` is this what you were looking for in rust-lang/reference#1603 (comment)? I'd say ignore the details about the specific error message (the fact that this gets reinterpreted as a char literal is 🤷), just that because this causes a lexer error we're effectively saving syntactical space like you wanted.
…r=chenyukang Reject raw lifetime followed by `'`, like regular lifetimes do See comment. We want to reject cases like `'r#long'id`, which currently gets interpreted as a raw lifetime (`'r#long`) followed by a lifetime (`'id`). This could have alternative lexes, such as an overlong char literal (`'r#long'`) followed by an identifier (`id`). To avoid committing to this in any case, let's reject the whole thing. `@mattheww,` is this what you were looking for in rust-lang/reference#1603 (comment)? I'd say ignore the details about the specific error message (the fact that this gets reinterpreted as a char literal is 🤷), just that because this causes a lexer error we're effectively saving syntactical space like you wanted.
…=wesleywiser Enforce that raw lifetimes must be valid raw identifiers Make sure that the identifier part of a raw lifetime is a valid raw identifier. This precludes `'r#_` and all module segment paths for now. I don't believe this is compelling to support. This was raised by `@ehuss` in rust-lang/reference#1603 (comment) (well, specifically the `'r#_` case), but I don't see why we shouldn't just make it consistent with raw identifiers.
@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. |
These are rejected by the lexer.
I pushed a commit specifying that This is a bit of an awkward issue around whether or not I did not want to define an identifier token that allowed |
See rust-lang/rust#126452