Recover when unclosed char literal is parsed as a lifetime in some positions #101293

compiler-errors · 2022-09-01T18:58:42Z

rust-highfive · 2022-09-01T18:58:46Z

(rust-highfive has picked a reviewer for you, use r? to override)

compiler-errors · 2022-09-01T19:00:41Z

compiler/rustc_parse/src/parser/expr.rs

@@ -1516,6 +1518,15 @@ impl<'a> Parser<'a> {
            || self.token.is_whole_block()
        {
            self.parse_block_expr(label, lo, BlockCheckMode::Default)
+        } else if !ate_colon
+            && (matches!(self.token.kind, token::CloseDelim(_) | token::Comma)


I'm using "close delim or comma or operator" here as a heuristic, because if we use something like "next token isn't colon" then we suggest 'a 0 => 'a' 0 which is nonsense.

compiler-errors · 2022-09-01T19:02:34Z

compiler/rustc_parse/src/parser/pat.rs

@@ -394,6 +394,21 @@ impl<'a> Parser<'a> {
            } else {
                PatKind::Path(qself, path)
            }
+        } else if matches!(self.token.kind, token::Lifetime(_))
+            && !self.look_ahead(1, |token| matches!(token.kind, token::Colon))


In pattern position, we're totally fine with using "next token isn't colon" as a heuristic. We could probably just always try to recover if it's a lifetime, because we never have 'a: label {} in a pattern position anyways, but it does keep us from suggesting something like let 'a: Ty = .. => let 'a': Ty = ..

Could we include this as a comment?

compiler-errors · 2022-09-01T19:03:05Z

src/test/ui/parser/issues/issue-93282.stderr

+   |
+help: add `'` to close the char literal
+   |
+LL |     f<'a',>


This is somewhat unfortunate, but teaching the parser to avoid suggesting this is just as hard as solving the turbofish problem I think, because at this point all the context we have is that we're parsing f < $EXPR where $EXPR begins with 'a

Hm, maybe I can avoid this if the prev token is <. Or maybe this suggestion is just nonsense and the PR needs to be scrapped.

It's fine, this is best effort.

compiler-errors · 2022-09-01T19:03:32Z

r? @estebank

bors · 2022-09-21T23:09:59Z

☔ The latest upstream changes (presumably #101558) made this pull request unmergeable. Please resolve the merge conflicts.

compiler-errors · 2022-10-20T16:41:52Z

I'm gonna re-roll this since it's been almost two months.

r? compiler

compiler-errors · 2022-10-20T18:34:59Z

r? compiler

rustbot wake up

compiler-errors · 2022-10-20T18:35:22Z

@jackh726 is also a busy person 🤣

r? diagnostics

estebank · 2022-10-21T02:28:08Z

compiler/rustc_parse/src/parser/expr.rs

+        err: impl FnOnce(&mut Self) -> DiagnosticBuilder<'a, ErrorGuaranteed>,
+    ) -> ast::Lit {
+        if let Some(mut diag) =
+            self.sess.span_diagnostic.steal_diagnostic(lifetime.span, StashKey::LifetimeIsChar)


I missed the introduction of this more principled version of this mechanism :)

estebank · 2022-10-21T02:30:08Z

compiler/rustc_parse/src/parser/pat.rs

@@ -394,6 +394,21 @@ impl<'a> Parser<'a> {
            } else {
                PatKind::Path(qself, path)
            }
+        } else if matches!(self.token.kind, token::Lifetime(_))
+            && !self.look_ahead(1, |token| matches!(token.kind, token::Colon))


Could we include this as a comment?

estebank · 2022-10-21T02:31:26Z

src/test/ui/parser/issues/issue-93282.stderr

+   |
+help: add `'` to close the char literal
+   |
+LL |     f<'a',>


It's fine, this is best effort.

estebank · 2022-10-21T02:32:03Z

@bors r+

bors · 2022-10-21T02:32:05Z

📌 Commit 0a92038fa1ae8d75ab1cd76e1ed535674799c6e7 has been approved by estebank

It is now in the queue for this repository.

compiler-errors · 2022-10-21T02:57:18Z

@bors r- i'll address that comment nit then re-r+

compiler-errors · 2022-10-22T20:52:07Z

@bors r=estebank

bors · 2022-10-22T20:52:09Z

📌 Commit 0270b50 has been approved by estebank

It is now in the queue for this repository.

Rollup of 6 pull requests Successful merges: - rust-lang#101293 (Recover when unclosed char literal is parsed as a lifetime in some positions) - rust-lang#101908 (Suggest let for assignment, and some code refactor) - rust-lang#103192 (rustdoc: Eliminate uses of `EarlyDocLinkResolver::all_traits`) - rust-lang#103226 (Check `needs_infer` before `needs_drop` during HIR generator analysis) - rust-lang#103249 (resolve: Revert "Set effective visibilities for imports more precisely") - rust-lang#103305 (Move some tests to more reasonable places) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

…-errors Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser interprets any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. In such cases it gives an error with a suggestion to add the trailing single quote, and then puts the appropriate char literal into the AST. This behaviour was introduced in rust-lang#101293. This is reasonable for a case like this: ``` let c = 'a; ``` because `'a'` is a valid char literal. It's less reasonable for a case like this: ``` let c = 'abc; ``` because `'abc'` is not a valid char literal. Prior to rust-lang#120329 this could result in some sub-optimal suggestions in error messages, but nothing else. But rust-lang#120329 changed `LitKind::from_token_lit` to assume that the char/byte/string literals it receives are valid, and to assert if not. This is reasonable because the lexer does not produce invalid char/byte/string literals in general. But in this "interpret label/lifetime as unclosed char literal" case the parser can produce an invalid char literal with contents such as `abc`, which triggers an assertion failure. This PR changes the parser so it's more cautious about interpreting labels/lifetimes as unclosed char literals. Fixes rust-lang#120397. r? `@compiler-errors`

Rollup merge of rust-lang#120460 - nnethercote:fix-120397, r=compiler-errors Be more careful about interpreting a label/lifetime as a mistyped char literal. Currently the parser interprets any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. In such cases it gives an error with a suggestion to add the trailing single quote, and then puts the appropriate char literal into the AST. This behaviour was introduced in rust-lang#101293. This is reasonable for a case like this: ``` let c = 'a; ``` because `'a'` is a valid char literal. It's less reasonable for a case like this: ``` let c = 'abc; ``` because `'abc'` is not a valid char literal. Prior to rust-lang#120329 this could result in some sub-optimal suggestions in error messages, but nothing else. But rust-lang#120329 changed `LitKind::from_token_lit` to assume that the char/byte/string literals it receives are valid, and to assert if not. This is reasonable because the lexer does not produce invalid char/byte/string literals in general. But in this "interpret label/lifetime as unclosed char literal" case the parser can produce an invalid char literal with contents such as `abc`, which triggers an assertion failure. This PR changes the parser so it's more cautious about interpreting labels/lifetimes as unclosed char literals. Fixes rust-lang#120397. r? `@compiler-errors`

rust-highfive assigned lcnr Sep 1, 2022

rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. labels Sep 1, 2022

This comment was marked as outdated.

Sign in to view

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 1, 2022

This comment was marked as outdated.

Sign in to view

compiler-errors force-pushed the lt-is-actually-char branch from dcc0614 to 339863b Compare September 1, 2022 18:59

compiler-errors commented Sep 1, 2022

View reviewed changes

rust-highfive assigned estebank and unassigned lcnr Sep 1, 2022

compiler-errors force-pushed the lt-is-actually-char branch from 339863b to 0a92038 Compare October 11, 2022 17:35

rust-highfive assigned jackh726 and unassigned estebank Oct 20, 2022

rust-highfive assigned davidtwco and unassigned jackh726 Oct 20, 2022

estebank approved these changes Oct 21, 2022

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 21, 2022

bors removed the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 21, 2022

bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Oct 21, 2022

davidtwco assigned estebank and unassigned davidtwco Oct 21, 2022

Recover unclosed char literal being parsed as lifetime

0270b50

compiler-errors force-pushed the lt-is-actually-char branch from 0a92038 to 0270b50 Compare October 22, 2022 06:57

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 22, 2022

Dylan-DPC mentioned this pull request Oct 23, 2022

Rollup of 6 pull requests #103431

Merged

bors merged commit e029c1f into rust-lang:master Oct 23, 2022

rustbot added this to the 1.66.0 milestone Oct 23, 2022

nnethercote mentioned this pull request Oct 27, 2022

Use token::Lit in ast::ExprKind::Lit. #102944

Merged

compiler-errors deleted the lt-is-actually-char branch November 2, 2022 03:00

nnethercote mentioned this pull request Jan 29, 2024

Be more careful about interpreting a label/lifetime as a mistyped char literal. #120460

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Recover when unclosed char literal is parsed as a lifetime in some positions #101293

Recover when unclosed char literal is parsed as a lifetime in some positions #101293

compiler-errors commented Sep 1, 2022

This comment was marked as outdated.

rust-highfive commented Sep 1, 2022

This comment was marked as outdated.

compiler-errors Sep 1, 2022

compiler-errors Sep 1, 2022 •

edited

Loading

estebank Oct 21, 2022

compiler-errors Oct 21, 2022

compiler-errors Sep 1, 2022 •

edited

Loading

compiler-errors Oct 20, 2022

estebank Oct 21, 2022

compiler-errors commented Sep 1, 2022

bors commented Sep 21, 2022

compiler-errors commented Oct 20, 2022

compiler-errors commented Oct 20, 2022

compiler-errors commented Oct 20, 2022

estebank Oct 21, 2022

estebank Oct 21, 2022

estebank Oct 21, 2022

estebank commented Oct 21, 2022

bors commented Oct 21, 2022

compiler-errors commented Oct 21, 2022

compiler-errors commented Oct 22, 2022

bors commented Oct 22, 2022

Recover when unclosed char literal is parsed as a lifetime in some positions #101293

Recover when unclosed char literal is parsed as a lifetime in some positions #101293

Conversation

compiler-errors commented Sep 1, 2022

This comment was marked as outdated.

rust-highfive commented Sep 1, 2022

This comment was marked as outdated.

Choose a reason for hiding this comment

compiler-errors Sep 1, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

compiler-errors Sep 1, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

compiler-errors commented Sep 1, 2022

bors commented Sep 21, 2022

compiler-errors commented Oct 20, 2022

compiler-errors commented Oct 20, 2022

compiler-errors commented Oct 20, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

estebank commented Oct 21, 2022

bors commented Oct 21, 2022

compiler-errors commented Oct 21, 2022

compiler-errors commented Oct 22, 2022

bors commented Oct 22, 2022

compiler-errors Sep 1, 2022 •

edited

Loading

compiler-errors Sep 1, 2022 •

edited

Loading