rust/compiler/rustc_parse/src/parser, branch 1.77.0

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`

Rollup merge of #118625 - ShE3py:expr-in-pats, r=WaffleLapkin

2024-01-29T12:56:51+00:00

Improve handling of expressions in patterns Closes #112593. Methodcalls' dots in patterns are silently recovered as commas (e.g. `Foo("".len())` -> `Foo("", len())`) so extra diagnostics are emitted: ```rs struct Foo(u8, String, u8); fn bar(foo: Foo) -> bool { match foo { Foo(4, "yippee".yeet(), 7) => true, _ => false } } ``` ``` error: expected one of `)`, `,`, `...`, `..=`, `..`, or `|`, found `.` --> main.rs:5:24 | 5 | Foo(4, "yippee".yeet(), 7) => true, | ^ | | | expected one of `)`, `,`, `...`, `..=`, `..`, or `|` | help: missing `,` error[E0531]: cannot find tuple struct or tuple variant `yeet` in this scope --> main.rs:5:25 | 5 | Foo(4, "yippee".yeet(), 7) => true, | ^^^^ not found in this scope error[E0023]: this pattern has 4 fields, but the corresponding tuple struct has 3 fields --> main.rs:5:13 | 1 | struct Foo(u8, String, u8); | -- ------ -- tuple struct has 3 fields ... 5 | Foo(4, "yippee".yeet(), 7) => true, | ^ ^^^^^^^^ ^^^^^^ ^ expected 3 fields, found 4 error: aborting due to 3 previous errors ``` This PR checks for patterns that ends with a dot and a lowercase ident (as structs/variants should be uppercase): ``` error: expected a pattern, found a method call --> main.rs:5:16 | 5 | Foo(4, "yippee".yeet(), 7) => true, | ^^^^^^^^^^^^^^^ method calls are not allowed in patterns error: aborting due to 1 previous error ``` Also check for expressions: ```rs fn is_idempotent(x: f32) -> bool { match x { x * x => true, _ => false, } } fn main() { let mut t: [i32; 5]; let t[0] = 1; } ``` ``` error: expected a pattern, found an expression --> main.rs:3:9 | 3 | x * x => true, | ^^^^^ arbitrary expressions are not allowed in patterns error: expected a pattern, found an expression --> main.rs:10:9 | 10 | let t[0] = 1; | ^^^^ arbitrary expressions are not allowed in patterns ``` Would be cool if the compiler could suggest adding a guard for `match`es, but I've no idea how to do it. --- `@rustbot` label +A-diagnostics +A-parser +A-patterns +C-enhancement

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.

Stop using `String` for error codes.

2024-01-28T20:41:41+00:00

Error codes are integers, but `String` is used everywhere to represent them. Gross! This commit introduces `ErrCode`, an integral newtype for error codes, replacing `String`. It also introduces a constant for every error code, e.g. `E0123`, and removes the `error_code!` macro. The constants are imported wherever used with `use rustc_errors::codes::*`. With the old code, we have three different ways to specify an error code at a use point: ``` error_code!(E0123) // macro call struct_span_code_err!(dcx, span, E0123, "msg"); // bare ident arg to macro call \#[diag(name, code = "E0123")] // string struct Diag; ``` With the new code, they all use the `E0123` constant. ``` E0123 // constant struct_span_code_err!(dcx, span, E0123, "msg"); // constant \#[diag(name, code = E0123)] // constant struct Diag; ``` The commit also changes the structure of the error code definitions: - `rustc_error_codes` now just defines a higher-order macro listing the used error codes and nothing else. - Because that's now the only thing in the `rustc_error_codes` crate, I moved it into the `lib.rs` file and removed the `error_codes.rs` file. - `rustc_errors` uses that macro to define everything, e.g. the error code constants and the `DIAGNOSTIC_TABLES`. This is in its new `codes.rs` file.

Handle methodcalls & operators in patterns

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

Rollup merge of #118182 - estebank:issue-118164, r=davidtwco

2024-01-27T09:48:46+00:00

Properly recover from trailing attr in body When encountering an attribute in a body, we try to recover from an attribute on an expression (as opposed to a statement). We need to properly clean up when the attribute is at the end of the body where a tail expression would be. Fix #118164, fix #118575.

Properly recover from trailing attr in body

2024-01-26T23:11:42+00:00

When encountering an attribute in a body, we try to recover from an attribute on an expression (as opposed to a statement). We need to properly clean up when the attribute is at the end of the body where a tail expression would be. Fix #118164.

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.