-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Reject raw lifetime followed by '
, like regular lifetimes do
#132341
Conversation
r? @chenyukang rustbot has assigned @chenyukang. Use |
Nominating as an easy decision because this is really new syntax and it saves space. If we want to go through with this, I'd say we also beta nominate it because raw lifetimes are landing next edition, though I guess we could land them out of sync because I doubt anyone will begin relying on this obscure behavior of a somewhat obscure feature in 6 weeks. |
'
like lifetimes'
, like regular lifetimes do
Yes, that's what I was thinking of. I think #132341 (comment) has a typo, and should be saying
|
@rfcbot merge |
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
@rfcbot reviewed |
1 similar comment
@rfcbot reviewed |
@rfcbot reveiwed |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
@rustbot labels -I-lang-nominated We discussed this in triage today, and as above, this seemed a clear call to us. |
Given that it's already rolled up though, I guess this can just merge now. |
@bors r- |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
@bors r=chenyukang |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#132341 (Reject raw lifetime followed by `'`, like regular lifetimes do) - rust-lang#132363 (Enforce that raw lifetimes must be valid raw identifiers) - rust-lang#132744 (add regression test for rust-lang#90781) - rust-lang#132754 (Simplify the internal API for declaring command-line options) - rust-lang#132772 (use `download-rustc="if-unchanged"` as a global default) - rust-lang#132774 (Use lld with non-LLVM backends) - rust-lang#132799 (Make `Ty::primitive_symbol` recognize `str`) r? `@ghost` `@rustbot` modify labels: rollup
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.
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#132341 (Reject raw lifetime followed by `'`, like regular lifetimes do) - rust-lang#132363 (Enforce that raw lifetimes must be valid raw identifiers) - rust-lang#132744 (add regression test for rust-lang#90781) - rust-lang#132754 (Simplify the internal API for declaring command-line options) - rust-lang#132772 (use `download-rustc="if-unchanged"` as a global default) - rust-lang#132774 (Use lld with non-LLVM backends) - rust-lang#132799 (Make `Ty::primitive_symbol` recognize `str`) r? `@ghost` `@rustbot` modify labels: rollup
[beta] backports - Use completion item indices instead of property matching rust-lang#132987, rust-lang/rust-analyzer#18503 - Reject raw lifetime followed by `'`, like regular lifetimes do rust-lang#132341 - Only disable cache if predicate has opaques within it rust-lang#132625 - rustdoc-search: case-sensitive only when capitals are used rust-lang#133043 r? cuviper
[beta] backports - Use completion item indices instead of property matching rust-lang#132987, rust-lang/rust-analyzer#18503 - Reject raw lifetime followed by `'`, like regular lifetimes do rust-lang#132341 - Only disable cache if predicate has opaques within it rust-lang#132625 - rustdoc-search: case-sensitive only when capitals are used rust-lang#133043 - (ci) Update macOS Xcode to 15 rust-lang#131570 r? cuviper
I think this caused #133479 |
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.