about summary refs log tree commit diff
path: root/compiler/rustc_parse/src
AgeCommit message (Collapse)AuthorLines
2024-02-29Remove unused diagnostic structr0cky-8/+0
2024-02-29Overhaul how stashed diagnostics work, again.Nicholas Nethercote-14/+15
Stashed errors used to be counted as errors, but could then be cancelled, leading to `ErrorGuaranteed` soundness holes. #120828 changed that, closing the soundness hole. But it introduced other difficulties because you sometimes have to account for pending stashed errors when making decisions about whether errors have occured/will occur and it's easy to overlook these. This commit aims for a middle ground. - Stashed errors (not warnings) are counted immediately as emitted errors, avoiding the possibility of forgetting to consider them. - The ability to cancel (or downgrade) stashed errors is eliminated, by disallowing the use of `steal_diagnostic` with errors, and introducing the more restrictive methods `try_steal_{modify,replace}_and_emit_err` that can be used instead. Other things: - `DiagnosticBuilder::stash` and `DiagCtxt::stash_diagnostic` now both return `Option<ErrorGuaranteed>`, which enables the removal of two `delayed_bug` calls and one `Ty::new_error_with_message` call. This is possible because we store error guarantees in `DiagCtxt::stashed_diagnostics`. - Storing the guarantees also saves us having to maintain a counter. - Calls to the `stashed_err_count` method are no longer necessary alongside calls to `has_errors`, which is a nice simplification, and eliminates two more `span_delayed_bug` calls and one FIXME comment. - Tests are added for three of the four fixed PRs mentioned below. - `issue-121108.rs`'s output improved slightly, omitting a non-useful error message. Fixes #121451. Fixes #121477. Fixes #121504. Fixes #121508.
2024-02-29Rollup merge of #121724 - nnethercote:LitKind-Err-for-floats, r=fmeaseMatthias Krüger-3/+7
Use `LitKind::Err` for malformed floats #121120 changed `StringReader::cook_lexer_literal` to return `LitKind::Err` for malformed integer literals. This commit does the same for float literals, for consistency. r? ``@fmease``
2024-02-28Use `LitKind::Err` for floats with unsupported bases.Nicholas Nethercote-1/+3
This slightly changes error messages in `float-field.rs`, but nothing of real importance.
2024-02-28Use `LitKind::Err` for floats with empty exponents.Nicholas Nethercote-2/+4
This prevents a follow-up type error in a test, which seems fine.
2024-02-28Rename `DiagnosticBuilder` as `Diag`.Nicholas Nethercote-66/+47
Much better! Note that this involves renaming (and updating the value of) `DIAGNOSTIC_BUILDER` in clippy.
2024-02-27Auto merge of #121285 - nnethercote:delayed_bug-audit, r=lcnrbors-18/+14
Delayed bug audit I went through all the calls to `delayed_bug` and `span_delayed_bug` and found a few places where they could be avoided. r? `@compiler-errors`
2024-02-27Refactor `take_for_recovery` call sites.Nicholas Nethercote-18/+14
To make them more concise and similar to each other.
2024-02-26Properly emit `expected ;` on `#[attr] expr`Lieselotte-4/+2
2024-02-25Add `ErrorGuaranteed` to `ast::ExprKind::Err`Lieselotte-151/+192
2024-02-25Add `ast::ExprKind::Dummy`Lieselotte-2/+3
2024-02-25Rollup merge of #121060 - clubby789:bool-newtypes, r=cjgillotMatthias Krüger-110/+141
Add newtypes for bool fields/params/return types Fixed all the cases of this found with some simple searches for `*/ bool` and `bool /*`; probably many more
2024-02-24Add asm label support to AST and HIRGary Guo-1/+1
2024-02-23compiler: clippy::complexity fixesMatthias Krüger-1/+1
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-21Rollup merge of #121379 - nnethercote:rm-unchecked_error_guaranteed, r=oli-obkLeón Orell Valerian Liehr-16/+4
Remove an `unchecked_error_guaranteed` call. If we abort immediately after complaining about the obsolete `impl Trait for ..` syntax, then we avoid reaching HIR lowering. This means we can use `TyKind::Dummy` instead of `TyKind::Err`. r? `@oli-obk`
2024-02-21Remove an `unchecked_error_guaranteed` call.Nicholas Nethercote-16/+4
If we abort immediately after complaining about the obsolete `impl Trait for ..` syntax, then we avoid reaching HIR lowering. This means we can use `TyKind::Dummy` instead of `TyKind::Err`.
2024-02-20Support async trait bounds in macrosMichael Goulet-3/+22
2024-02-20Use `Recovered` moreclubby789-12/+13
2024-02-20Add newtype for trailing in parserclubby789-21/+30
2024-02-20Add newtype for parser recoveryclubby789-41/+54
2024-02-20Add newtype for raw identsclubby789-39/+47
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-19Prefer `DiagnosticBuilder` over `Diagnostic` in diagnostic modifiers.Nicholas Nethercote-16/+14
There are lots of functions that modify a diagnostic. This can be via a `&mut Diagnostic` or a `&mut DiagnosticBuilder`, because the latter type wraps the former and impls `DerefMut`. This commit converts all the `&mut Diagnostic` occurrences to `&mut DiagnosticBuilder`. This is a step towards greatly simplifying `Diagnostic`. Some of the relevant function are made generic, because they deal with both errors and warnings. No function bodies are changed, because all the modifier methods are available on both `Diagnostic` and `DiagnosticBuilder`.
2024-02-18Rollup merge of #121237 - Urgau:better-cargo-heuristic, r=compiler-errorsLeón Orell Valerian Liehr-1/+1
Use better heuristic for printing Cargo specific diagnostics It was [reported](https://github.com/rust-lang/rust/issues/82450#issuecomment-1948574677) in the check-cfg call for testing that the Rust for Linux project is setting the `CARGO` env without compiling with it, which is an issue since we are using the `CARGO` env as a proxy for "was launched from Cargo". This PR switch to the `CARGO_CRATE_NAME` [Cargo env](https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-crates), which shouldn't collide (as much) with other build systems. I also took the opportunity to consolidate all the checks under the same function.
2024-02-17Rollup merge of #121231 - matthiaskrgr:cloone, r=compiler-errorsMatthias Krüger-2/+2
remove a couple of redundant clones
2024-02-17Rollup merge of #121085 - davidtwco:always-eager-diagnostics, r=nnethercoteMatthias Krüger-8/+11
errors: only eagerly translate subdiagnostics Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). r? ```@nnethercote```
2024-02-17Use better heuristic for printing Cargo specific diagnosticsUrgau-1/+1
2024-02-17remove a couple of redundant clonesMatthias Krüger-2/+2
2024-02-16Rollup merge of #121109 - nnethercote:TyKind-Err-guar-2, r=oli-obkGuillaume Gomez-21/+42
Add an ErrorGuaranteed to ast::TyKind::Err (attempt 2) This makes it more like `hir::TyKind::Err`, and avoids a `has_errors` assertion in `LoweringContext::lower_ty_direct`. r? ```@oli-obk```
2024-02-15errors: only eagerly translate subdiagnosticsDavid Wood-8/+11
Subdiagnostics don't need to be lazily translated, they can always be eagerly translated. Eager translation is slightly more complex as we need to have a `DiagCtxt` available to perform the translation, which involves slightly more threading of that context. This slight increase in complexity should enable later simplifications - like passing `DiagCtxt` into `AddToDiagnostic` and moving Fluent messages into the diagnostic structs rather than having them in separate files (working on that was what led to this change). Signed-off-by: David Wood <david@davidtw.co>
2024-02-15Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.Nicholas Nethercote-15/+17
This mostly works well, and eliminates a couple of delayed bugs. One annoying thing is that we should really also add an `ErrorGuaranteed` to `proc_macro::bridge::LitKind::Err`. But that's difficult because `proc_macro` doesn't have access to `ErrorGuaranteed`, so we have to fake it.
2024-02-15Make `emit_unescape_error` return `Option<ErrorGuaranteed>`.Nicholas Nethercote-40/+34
And use the result in `cook_common` to decide whether to return an error token.
2024-02-15Remove `LitError::LexerError`.Nicholas Nethercote-15/+15
`cook_lexer_literal` can emit an error about an invalid int literal but then return a non-`Err` token. And then `integer_lit` has to account for this to avoid printing a redundant error message. This commit changes `cook_lexer_literal` to return `Err` in that case. Then `integer_lit` doesn't need the special case, and `LitError::LexerError` can be removed.
2024-02-15Add an `ErrorGuaranteed` to `ast::TyKind::Err`.Nicholas Nethercote-21/+42
This makes it more like `hir::TyKind::Err`, and avoids a `span_delayed_bug` call in `LoweringContext::lower_ty_direct`. It also requires adding `ast::TyKind::Dummy`, now that `ast::TyKind::Err` can't be used for that purpose in the absence of an error emission. There are a couple of cases that aren't as neat as I would have liked, marked with `FIXME` comments.
2024-02-12Properly handle `async` blocks and `fn`s in `if` exprs without `else`Esteban Küber-1/+1
When encountering a tail expression in the then arm of an `if` expression without an `else` arm, account for `async fn` and `async` blocks to suggest `return`ing the value and pointing at the return type of the `async fn`. We now also account for AFIT when looking for the return type to point at. Fix #115405.
2024-02-12Lower anonymous structs or unions to HIRFrank King-2/+3
2024-02-09Rollup merge of #120693 - nnethercote:invert-diagnostic-lints, r=davidtwcoMatthias Krüger-1/+3
Invert diagnostic lints. That is, change `diagnostic_outside_of_impl` and `untranslatable_diagnostic` from `allow` to `deny`, because more than half of the compiler has been converted to use translated diagnostics. This commit removes more `deny` attributes than it adds `allow` attributes, which proves that this change is warranted. r? ````@davidtwco````
2024-02-08Auto merge of #120767 - matthiaskrgr:rollup-0k8ib1c, r=matthiaskrgrbors-6/+3
Rollup of 9 pull requests Successful merges: - #119592 (resolve: Unload speculatively resolved crates before freezing cstore) - #120103 (Make it so that async-fn-in-trait is compatible with a concrete future in implementation) - #120206 (hir: Make sure all `HirId`s have corresponding HIR `Node`s) - #120214 (match lowering: consistently lower bindings deepest-first) - #120688 (GVN: also turn moves into copies with projections) - #120702 (docs: also check the inline stmt during redundant link check) - #120727 (exhaustiveness: Prefer "`0..MAX` not covered" to "`_` not covered") - #120734 (Add `SubdiagnosticMessageOp` as a trait alias.) - #120739 (improve pretty printing for associated items in trait objects) r? `@ghost` `@rustbot` modify labels: rollup
2024-02-08Continue to borrowck even if there were previous errorsOli Scherer-1/+11
2024-02-08Add `SubdiagnosticMessageOp` as a trait alias.Nicholas Nethercote-6/+3
It avoids a lot of repetition.
2024-02-06Invert diagnostic lints.Nicholas Nethercote-1/+3
That is, change `diagnostic_outside_of_impl` and `untranslatable_diagnostic` from `allow` to `deny`, because more than half of the compiler has be converted to use translated diagnostics. This commit removes more `deny` attributes than it adds `allow` attributes, which proves that this change is warranted.
2024-02-06Auto merge of #120392 - compiler-errors:async-bound-modifier, r=davidtwco,fmeasebors-7/+33
Introduce support for `async` bound modifier on `Fn*` traits Adds `async` to the list of `TraitBoundModifiers`, which instructs AST lowering to map the trait to an async flavor of the trait. For now, this is only supported for `Fn*` to `AsyncFn*`, and I expect that this manual mapping via lang items will be replaced with a better system in the future. The motivation for adding these bounds is to separate the users of async closures from the exact trait desugaring of their callable bounds. Instead of users needing to be concerned with the `AsyncFn` trait, they should be able to write `async Fn()` and it will desugar to whatever underlying trait we decide is best for the lowering of async closures. Note: rustfmt support can be done in the rustfmt repo after a subtree sync.
2024-02-03Rollup merge of #120592 - trevyn:cleanup-to-string, r=NilstriebMatthias Krüger-3/+3
Remove unnecessary `.to_string()`/`.as_str()`s
2024-02-02Remove unnecessary `.to_string()`/`.as_str()`strevyn-3/+3
2024-02-03Fix an incorrect comment.Nicholas Nethercote-1/+1
2024-01-31Better error message in ed 2015Michael Goulet-2/+22
2024-01-31Add async bound modifier to enable async Fn boundsMichael Goulet-5/+11
2024-01-30Rollup merge of #120460 - nnethercote:fix-120397, r=compiler-errorsGuillaume Gomez-10/+25
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`
2024-01-29Rollup merge of #118625 - ShE3py:expr-in-pats, r=WaffleLapkinDylan DPC-13/+168
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