rust/compiler/rustc_parse/src/parser/expr.rs, branch 1.77.1

Rollup merge of #120460 - nnethercote:fix-120397, r=compiler-errors

2024-01-30T10:19:19+00:00

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 #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 #120329 this could result in some sub-optimal suggestions in error messages, but nothing else. But #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 #120397. r? `@compiler-errors`

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

2024-01-29T00:25:09+00:00

Currently the parser will interpret any label/lifetime in certain positions as a mistyped char literal, on the assumption that the trailing single quote was accidentally omitted. This is reasonable for a something like 'a (because 'a' would be valid) but not reasonable for a something like 'abc (because 'abc' is not valid). This commit restricts this behaviour only to labels/lifetimes that would be valid char literals, via the new `could_be_unclosed_char_literal` function. The commit also augments the `label-is-actually-char.rs` test in a couple of ways: - Adds testing of labels/lifetimes with identifiers longer than one char, e.g. 'abc. - Adds a new match with simpler patterns, because the `recover_unclosed_char` call in `parse_pat_with_range_pat` was not being exercised (in this test or any other ui tests). Fixes #120397, an assertion failure, which was caused by this behaviour in the parser interacting with some new stricter char literal checking added in #120329.

Tweak comment and naming for `recover_unclosed_char`.

2024-01-28T22:33:49+00:00

Because it can be used for a lifetime or a label.

Handle methodcalls & operators in patterns

2024-01-28T15:12:21+00:00

Rollup merge of #119342 - sjwang05:issue-112254, r=wesleywiser

2024-01-26T22:15:49+00:00

Emit suggestion when trying to write exclusive ranges as `..<` Closes #112254

Rollup merge of #120063 - clubby789:remove-box-handling, r=Nilstrieb

2024-01-20T19:06:34+00:00

Remove special handling of `box` expressions from parser #108471 added a temporary hack to parse `box expr`. It's been almost a year since then, so I think it's safe to remove the special handling. As a drive-by cleanup, move `parser/removed-syntax*` tests to their own directory.

Suggest wrapping mac args in parens rather than the whole expression

2024-01-18T00:01:13+00:00

Remove `box ` recovery

2024-01-17T21:16:22+00:00

Rename consuming chaining methods on `DiagnosticBuilder`.

2024-01-09T20:40:00+00:00

In #119606 I added them and used a `_mv` suffix, but that wasn't great. A `with_` prefix has three different existing uses. - Constructors, e.g. `Vec::with_capacity`. - Wrappers that provide an environment to execute some code, e.g. `with_session_globals`. - Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`. The third case is exactly what we want, so this commit changes `DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`. Thanks to @compiler-errors for the suggestion.

Rename `{create,emit}_warning` as `{create,emit}_warn`.

2024-01-09T20:33:06+00:00

For consistency with `warn`/`struct_warn`, and also `{create,emit}_err`, all of which use an abbreviated form.