https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.77.1 2024-01-29T12:56:51+00:00 2024-01-29T12:56:51+00:00 Dylan DPC 99973273+Dylan-DPC@users.noreply.github.com 2024-01-29T12:56:51+00:00 urn:sha1:0138151c21cbfabad410ebfb4a082edafed2e067 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 2024-01-28T20:41:41+00:00 Nicholas Nethercote n.nethercote@gmail.com 2024-01-13T23:57:07+00:00 urn:sha1:5d9dfbd08f38c2a9bc71d39de8f5c7776afe0f9e 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. 2024-01-28T15:12:21+00:00 Lieselotte 52315535+she3py@users.noreply.github.com 2024-01-28T15:12:21+00:00 urn:sha1:6f014a81b2466c2abdae4c06ff81fae7e1bc006c 2024-01-19T07:15:03+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-01-19T07:15:03+00:00 urn:sha1:2e4c6fc9985c5675e8148886cf83d7d683ac80a4 Deny braced macro invocations in let-else Fixes #119057 Pending T-lang decision cc `@dtolnay` 2024-01-18T09:34:17+00:00 Matthias Krüger matthias.krueger@famsik.de 2024-01-18T09:34:17+00:00 urn:sha1:ff8c7a7816fa1ca3507bf708efece6222b7b48b0 Detect `NulInCStr` error earlier. By making it an `EscapeError` instead of a `LitError`. This makes it like the other errors produced when checking string literals contents, e.g. for invalid escape sequences or bare CR chars. NOTE: this means these errors are issued earlier, before expansion, which changes behaviour. It will be possible to move the check back to the later point if desired. If that happens, it's likely that all the string literal contents checks will be delayed together. One nice thing about this: the old approach had some code in `report_lit_error` to calculate the span of the nul char from a range. This code used a hardwired `+2` to account for the `c"` at the start of a C string literal, but this should have changed to a `+3` for raw C string literals to account for the `cr"`, which meant that the caret in `cr"` nul error messages was one short of where it should have been. The new approach doesn't need any of this and avoids the off-by-one error. r? ```@fee1-dead``` 2024-01-18T00:01:13+00:00 Michael Goulet michael@errs.io 2023-12-18T03:01:05+00:00 urn:sha1:ec263df5e440598159f19a42c104c3b5f13888a0 2024-01-12T21:59:47+00:00 sjwang05 63834813+sjwang05@users.noreply.github.com 2023-12-27T02:34:44+00:00 urn:sha1:aa8ecd0652afbecd6549d2f6e53c0a5f6aa76d8f 2024-01-12T05:19:37+00:00 Nicholas Nethercote n.nethercote@gmail.com 2023-12-06T22:53:08+00:00 urn:sha1:9018d2c455df78d3f2900b4ced3ed63962e4f11e By making it an `EscapeError` instead of a `LitError`. This makes it like the other errors produced when checking string literals contents, e.g. for invalid escape sequences or bare CR chars. NOTE: this means these errors are issued earlier, before expansion, which changes behaviour. It will be possible to move the check back to the later point if desired. If that happens, it's likely that all the string literal contents checks will be delayed together. One nice thing about this: the old approach had some code in `report_lit_error` to calculate the span of the nul char from a range. This code used a hardwired `+2` to account for the `c"` at the start of a C string literal, but this should have changed to a `+3` for raw C string literals to account for the `cr"`, which meant that the caret in `cr"` nul error messages was one short of where it should have been. The new approach doesn't need any of this and avoids the off-by-one error. 2024-01-05T15:57:21+00:00 Michael Goulet michael@errs.io 2024-01-05T15:57:21+00:00 urn:sha1:f361b591efb7c05b9f498f2b4eb6381d522094ce Cleanup error handlers: round 5 More rustc_errors cleanups. A sequel to https://github.com/rust-lang/rust/pull/119171. r? ````@compiler-errors```` 2024-01-04T21:44:14+00:00 bors bors@rust-lang.org 2024-01-04T21:44:14+00:00 urn:sha1:f688dd684faca5b31b156fac2c6e0ae81fc9bc90 Rollup of 10 pull requests Successful merges: - #118521 (Enable address sanitizer for MSVC targets using INFERASANLIBS linker flag) - #119026 (std::net::bind using -1 for openbsd which in turn sets it to somaxconn.) - #119195 (Make named_asm_labels lint not trigger on unicode and trigger on format args) - #119204 (macro_rules: Less hacky heuristic for using `tt` metavariable spans) - #119362 (Make `derive(Trait)` suggestion more accurate) - #119397 (Recover parentheses in range patterns) - #119417 (Uplift some miscellaneous coroutine-specific machinery into `check_closure`) - #119539 (Fix typos) - #119540 (Don't synthesize host effect args inside trait object types) - #119555 (Add codegen test for RVO on MaybeUninit) r? `@ghost` `@rustbot` modify labels: rollup