about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/errors.rs
AgeCommit message (Collapse)AuthorLines
2024-04-23Rollup merge of #124218 - Xiretza:subsubdiagnostics, r=davidtwcoLeón Orell Valerian Liehr-1/+1
Allow nesting subdiagnostics in #[derive(Subdiagnostic)]
2024-04-23Rollup merge of #124099 - voidc:disallow-ambiguous-expr-attrs, r=davidtwcoMatthias Krüger-0/+9
Disallow ambiguous attributes on expressions This implements the suggestion in [#15701](https://github.com/rust-lang/rust/issues/15701#issuecomment-2033124217) to disallow ambiguous outer attributes on expressions. This should resolve one of the concerns blocking the stabilization of `stmt_expr_attributes`.
2024-04-22Improve handling of expr->field errorsSasha Pourcelot-0/+9
The current message for "`->` used for field access" is the following: ```rust error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `->` --> src/main.rs:2:6 | 2 | a->b; | ^^ expected one of 8 possible tokens ``` (playground link[1]) This PR tries to address this by adding a dedicated error message and recovery. The proposed error message is: ``` error: `->` used for field access or method call --> ./tiny_test.rs:2:6 | 2 | a->b; | ^^ help: try using `.` instead | = help: the `.` operator will dereference the value if needed ``` (feel free to bikeshed it as much as necessary) [1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7f8b6f4433aa7866124123575456f54e Signed-off-by: Sasha Pourcelot <sasha.pourcelot@protonmail.com>
2024-04-21Pass translation closure to add_to_diag_with() as referenceXiretza-1/+1
2024-04-18Disallow ambiguous attributes on expressionsDominik Stolz-0/+9
2024-03-27Implement `mut ref`/`mut ref mut`Jules Bertholet-8/+0
2024-03-26Rollup merge of #122120 - fmease:sugg-assoc-ty-bound-on-eq-bound, ↵Matthias Krüger-4/+13
r=compiler-errors Suggest associated type bounds on problematic associated equality bounds Fixes #105056. TL;DR: Suggest `Trait<Ty: Bound>` on `Trait<Ty = Bound>` in Rust >=2021. ~~Blocked on #122055 (stabilization of `associated_type_bounds`), I'd say.~~ (merged)
2024-03-24Rollup merge of #122217 - estebank:issue-119685, r=fmeaseMatthias Krüger-1/+21
Handle str literals written with `'` lexed as lifetime Given `'hello world'` and `'1 str', provide a structured suggestion for a valid string literal: ``` error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-3.rs:2:26 | LL | println!('hello world'); | ^^^^ | help: if you meant to write a `str` literal, use double quotes | LL | println!("hello world"); | ~ ~ ``` ``` error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-1.rs:2:20 | LL | println!('1 + 1'); | ^^^^ | help: if you meant to write a `str` literal, use double quotes | LL | println!("1 + 1"); | ~ ~ ``` Fix #119685.
2024-03-23Suggest assoc ty bound on lifetime in eq constraintLeón Orell Valerian Liehr-4/+13
2024-03-21Remove non-useful code path.Nicholas Nethercote-7/+0
It has no effect on anything in the test suite.
2024-03-17Use shorter span for existing `'` -> `"` structured suggestionEsteban Küber-1/+10
2024-03-17Handle str literals written with `'` lexed as lifetimeEsteban Küber-0/+11
Given `'hello world'` and `'1 str', provide a structured suggestion for a valid string literal: ``` error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-3.rs:2:26 | LL | println!('hello world'); | ^^^^ | help: if you meant to write a `str` literal, use double quotes | LL | println!("hello world"); | ~ ~ ``` ``` error[E0762]: unterminated character literal --> $DIR/lex-bad-str-literal-as-char-1.rs:2:20 | LL | println!('1 + 1'); | ^^^^ | help: if you meant to write a `str` literal, use double quotes | LL | println!("1 + 1"); | ~ ~ ``` Fix #119685.
2024-03-11Rename `AddToDiagnostic` as `Subdiagnostic`.Nicholas Nethercote-9/+9
To match `derive(Subdiagnostic)`. Also rename `add_to_diagnostic{,_with}` as `add_to_diag{,_with}`.
2024-03-11Rename `IntoDiagnostic` as `Diagnostic`.Nicholas Nethercote-6/+6
To match `derive(Diagnostic)`. Also rename `into_diagnostic` as `into_diag`.
2024-03-05Rename `SubdiagnosticMessageOp` as `SubdiagMessageOp`.Nicholas Nethercote-2/+2
2024-02-29Remove unused diagnostic structr0cky-8/+0
2024-02-28Rename `DiagnosticBuilder` as `Diag`.Nicholas Nethercote-7/+7
Much better! Note that this involves renaming (and updating the value of) `DIAGNOSTIC_BUILDER` in clippy.
2024-02-22Make some `IntoDiagnostic` impls generic.Nicholas Nethercote-4/+4
PR #119097 made the decision to make all `IntoDiagnostic` impls generic, because this allowed a bunch of nice cleanups. But four hand-written impls were unintentionally overlooked. This commit makes them generic.
2024-02-20Support async trait bounds in macrosMichael Goulet-0/+7
2024-02-20Reduce capabilities of `Diagnostic`.Nicholas Nethercote-2/+6
Currently many diagnostic modifier methods are available on both `Diagnostic` and `DiagnosticBuilder`. This commit removes most of them from `Diagnostic`. To minimize the diff size, it keeps them within `diagnostic.rs` but changes the surrounding `impl Diagnostic` block to `impl DiagnosticBuilder`. (I intend to move things around later, to give a more sensible code layout.) `Diagnostic` keeps a few methods that it still needs, like `sub`, `arg`, and `replace_args`. The `forward!` macro, which defined two additional methods per call (e.g. `note` and `with_note`), is replaced by the `with_fn!` macro, which defines one additional method per call (e.g. `with_note`). It's now also only used when necessary -- not all modifier methods currently need a `with_*` form. (New ones can be easily added as necessary.) All this also requires changing `trait AddToDiagnostic` so its methods take `DiagnosticBuilder` instead of `Diagnostic`, which leads to many mechanical changes. `SubdiagnosticMessageOp` gains a type parameter `G`. There are three subdiagnostics -- `DelayedAtWithoutNewline`, `DelayedAtWithNewline`, and `InvalidFlushedDelayedDiagnosticLevel` -- that are created within the diagnostics machinery and appended to external diagnostics. These are handled at the `Diagnostic` level, which means it's now hard to construct them via `derive(Diagnostic)`, so instead we construct them by hand. This has no effect on what they look like when printed. There are lots of new `allow` markers for `untranslatable_diagnostics` and `diagnostics_outside_of_impl`. This is because `#[rustc_lint_diagnostics]` annotations were present on the `Diagnostic` modifier methods, but missing from the `DiagnosticBuilder` modifier methods. They're now present.
2024-02-17Use better heuristic for printing Cargo specific diagnosticsUrgau-1/+1
2024-02-08Add `SubdiagnosticMessageOp` as a trait alias.Nicholas Nethercote-6/+3
It avoids a lot of repetition.
2024-01-31Better error message in ed 2015Michael Goulet-0/+9
2024-01-29Rollup merge of #118625 - ShE3py:expr-in-pats, r=WaffleLapkinDylan DPC-0/+12
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-29Stop using `String` for error codes.Nicholas Nethercote-9/+9
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-28Handle methodcalls & operators in patternsLieselotte-0/+12
2024-01-19Rollup merge of #119062 - compiler-errors:asm-in-let-else, r=davidtwco,est31Matthias Krüger-12/+25
Deny braced macro invocations in let-else Fixes #119057 Pending T-lang decision cc `@dtolnay`
2024-01-18Rollup merge of #119172 - nnethercote:earlier-NulInCStr, r=petrochenkovMatthias Krüger-0/+5
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-18Suggest wrapping mac args in parens rather than the whole expressionMichael Goulet-12/+25
2024-01-12Suggest quoting unquoted idents in attrssjwang05-0/+19
2024-01-12Detect `NulInCStr` error earlier.Nicholas Nethercote-0/+5
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-05Rollup merge of #119538 - nnethercote:cleanup-errors-5, r=compiler-errorsMichael Goulet-4/+4
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-04Auto merge of #119569 - matthiaskrgr:rollup-4packja, r=matthiaskrgrbors-0/+21
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
2024-01-03Recover parentheses in range patternsLieselotte-0/+21
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
2024-01-03Rename some `Diagnostic` setters.Nicholas Nethercote-4/+4
`Diagnostic` has 40 methods that return `&mut Self` and could be considered setters. Four of them have a `set_` prefix. This doesn't seem necessary for a type that implements the builder pattern. This commit removes the `set_` prefixes on those four methods.
2024-01-02Make offset_of field parsing use metavariable which handles any spacingGeorge Bateman-0/+8
2023-12-27Introduce `const Trait` (always-const trait bounds)León Orell Valerian Liehr-17/+1
2023-12-23Give `DiagnosticBuilder` a default type.Nicholas Nethercote-12/+4
`IntoDiagnostic` defaults to `ErrorGuaranteed`, because errors are the most common diagnostic level. It makes sense to do likewise for the closely-related (and much more widely used) `DiagnosticBuilder` type, letting us write `DiagnosticBuilder<'a, ErrorGuaranteed>` as just `DiagnosticBuilder<'a>`. This cuts over 200 lines of code due to many multi-line things becoming single line things.
2023-12-19Add `level` arg to `into_diagnostic`.Nicholas Nethercote-33/+47
And make all hand-written `IntoDiagnostic` impls generic, by using `DiagnosticBuilder::new(dcx, level, ...)` instead of e.g. `dcx.struct_err(...)`. This means the `create_*` functions are the source of the error level. This change will let us remove `struct_diagnostic`. Note: `#[rustc_lint_diagnostics]` is added to `DiagnosticBuilder::new`, it's necessary to pass diagnostics tests now that it's used in `into_diagnostic` functions.
2023-12-18Rename many `DiagCtxt` arguments.Nicholas Nethercote-4/+4
2023-12-18Rename `Handler` as `DiagCtxt`.Nicholas Nethercote-2/+2
2023-12-14Avoid `struct_diagnostic` where possible.Nicholas Nethercote-2/+2
It's necessary for `derive(Diagnostic)`, but is best avoided elsewhere because there are clearer alternatives. This required adding `Handler::struct_almost_fatal`.
2023-12-08Support async gen fnMichael Goulet-7/+0
2023-12-07Rollup merge of #116420 - bvanjoi:fix-116203, r=NilstriebMatthias Krüger-1/+1
discard invalid spans in external blocks Fixes #116203 This PR has discarded the invalid `const_span`, thereby making the format more neat. r? ``@Nilstrieb``
2023-12-06Auto merge of #118655 - compiler-errors:rollup-vrngyzn, r=compiler-errorsbors-5/+5
Rollup of 9 pull requests Successful merges: - #117793 (Update variable name to fix `unused_variables` warning) - #118123 (Add support for making lib features internal) - #118268 (Pretty print `Fn<(..., ...)>` trait refs with parentheses (almost) always) - #118346 (Add `deeply_normalize_for_diagnostics`, use it in coherence) - #118350 (Simplify Default for tuples) - #118450 (Use OnceCell in cell module documentation) - #118585 (Fix parser ICE when recovering `dyn`/`impl` after `for<...>`) - #118587 (Cleanup error handlers some more) - #118642 (bootstrap(builder.rs): Don't explicitly warn against `semicolon_in_expressions_from_macros`) r? `@ghost` `@rustbot` modify labels: rollup
2023-12-04Make async gen fn an errorEric Holk-0/+7
2023-12-04De-genericize some `IntoDiagnostic` impls.Nicholas Nethercote-5/+5
These impls are all needed for just a single `IntoDiagnostic` type, not a family of them. Note that `ErrorGuaranteed` is the default type parameter for `IntoDiagnostic`.
2023-11-29Account for `(pat if expr) => {}`Esteban Küber-0/+18
When encountering match arm (pat if expr) => {}, recover and suggest removing parentheses. Fix #100825.
2023-11-29More accurate span for unnecessary parens suggestionEsteban Küber-4/+2
2023-11-29Rollup merge of #118191 - estebank:let-chain-typo, r=compiler-errorsMatthias Krüger-0/+26
Suggest `let` or `==` on typo'd let-chain When encountering a bare assignment in a let-chain, suggest turning the assignment into a `let` expression or an equality check. ``` error: expected expression, found `let` statement --> $DIR/bad-if-let-suggestion.rs:5:8 | LL | if let x = 1 && i = 2 {} | ^^^^^^^^^ | = note: only supported directly in conditions of `if` and `while` expressions help: you might have meant to continue the let-chain | LL | if let x = 1 && let i = 2 {} | +++ help: you might have meant to compare for equality | LL | if let x = 1 && i == 2 {} | + ```