summary refs log tree commit diff
path: root/compiler/rustc_parse/src/parser
AgeCommit message (Collapse)AuthorLines
2024-03-14Rename `ast::StmtKind::Local` into `ast::StmtKind::Let`Guillaume Gomez-4/+4
2024-03-12Fix ICE in diagnostics for parenthesized type argumentsDaniel Sedlak-21/+31
2024-03-11Rollup merge of #122152 - wutchzone:120892, r=fmeaseJubilee-2/+84
Improve diagnostics for parenthesized type arguments Fixes #120892 r? fmease
2024-03-11Rename `AddToDiagnostic` as `Subdiagnostic`.Nicholas Nethercote-6/+6
To match `derive(Subdiagnostic)`. Also rename `add_to_diagnostic{,_with}` as `add_to_diag{,_with}`.
2024-03-11Rename `IntoDiagnosticArg` as `IntoDiagArg`.Nicholas Nethercote-1/+1
Also rename `into_diagnostic_arg` as `into_diag_arg`, and `NotIntoDiagnosticArg` as `NotInotDiagArg`.
2024-03-09Improve diagnostics for parenthesized type argumentsDaniel Sedlak-2/+84
2024-03-09Rollup merge of #122160 - jieyouxu:eager-translate-help-use-latest-edition, ↵Matthias Krüger-1/+1
r=cjgillot Eagerly translate `HelpUseLatestEdition` in parser diagnostics Fixes #122130. This makes me suspicious of these other two usage of `add_to_diagnostic()`. Would they *also* crash? I haven't attempted to construct test cases for them. ``` compiler/rustc_parse/src/parser/expr.rs 3453: errors::HelpUseLatestEdition::new().add_to_diagnostic(e); compiler/rustc_hir_typeck/src/expr.rs 2603: HelpUseLatestEdition::new().add_to_diagnostic(&mut err); ``` This also seems like a footgun?
2024-03-08Rollup merge of #121563 - Jarcho:use_cf, r=petrochenkovMatthias Krüger-7/+9
Use `ControlFlow` in visitors. Follow up to #121256 This does have a few small behaviour changes in some diagnostic output where the visitor will now find the first match rather than the last match. The change in `find_anon_types.rs` has the only affected test. I don't see this being an issue as the last occurrence isn't any better of a choice than the first.
2024-03-08Rollup merge of #119365 - nbdd0121:asm-goto, r=AmanieuMatthias Krüger-1/+1
Add asm goto support to `asm!` Tracking issue: #119364 This PR implements asm-goto support, using the syntax described in "future possibilities" section of [RFC2873](https://rust-lang.github.io/rfcs/2873-inline-asm.html#asm-goto). Currently I have only implemented the `label` part, not the `fallthrough` part (i.e. fallthrough is implicit). This doesn't reduce the expressive though, since you can use label-break to get arbitrary control flow or simply set a value and rely on jump threading optimisation to get the desired control flow. I can add that later if deemed necessary. r? ``@Amanieu`` cc ``@ojeda``
2024-03-07Eagerly translate HelpUseLatestEdition in parser diagnostics许杰友 Jieyou Xu (Joe)-1/+1
2024-03-06Cancel parsing ever made during recoveryclubby789-6/+10
2024-03-05Use `ControlFlow` in AST visitors.Jason Newcomb-7/+9
2024-03-05Rename `BuiltinLintDiagnostics` as `BuiltinLintDiag`.Nicholas Nethercote-2/+2
Not the dropping of the trailing `s` -- this type describes a single diagnostic and its name should be singular.
2024-03-05Rename all `ParseSess` variables/fields/lifetimes as `psess`.Nicholas Nethercote-96/+97
Existing names for values of this type are `sess`, `parse_sess`, `parse_session`, and `ps`. `sess` is particularly annoying because that's also used for `Session` values, which are often co-located, and it can be difficult to know which type a value named `sess` refers to. (That annoyance is the main motivation for this change.) `psess` is nice and short, which is good for a name used this much. The commit also renames some `parse_sess_created` values as `psess_created`.
2024-03-02Auto merge of #121657 - estebank:issue-119665, r=davidtwcobors-12/+66
Detect more cases of `=` to `:` typo When a `Local` is fully parsed, but not followed by a `;`, keep the `:` span arround and mention it. If the type could continue being parsed as an expression, suggest replacing the `:` with a `=`. ``` error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` --> file.rs:2:32 | 2 | let _: std::env::temp_dir().join("foo"); | - ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=` | | | while parsing the type for `_` | help: use `=` if you meant to assign ``` Fix #119665.
2024-03-01Detect more cases of `=` to `:` typoEsteban Küber-12/+66
When a `Local` is fully parsed, but not followed by a `;`, keep the `:` span arround and mention it. If the type could continue being parsed as an expression, suggest replacing the `:` with a `=`. ``` error: expected one of `!`, `+`, `->`, `::`, `;`, or `=`, found `.` --> file.rs:2:32 | 2 | let _: std::env::temp_dir().join("foo"); | - ^ expected one of `!`, `+`, `->`, `::`, `;`, or `=` | | | while parsing the type for `_` | help: use `=` if you meant to assign ``` Fix #119665.
2024-02-29Rollup merge of #121326 - ↵Matthias Krüger-6/+11
fmease:detect-empty-leading-where-clauses-on-ty-aliases, r=compiler-errors Detect empty leading where clauses on type aliases 1. commit: refactor the AST of type alias where clauses * I could no longer bear the look of `.0.1` and `.1.0` * Arguably moving `split` out of `TyAlias` into a substruct might not make that much sense from a semantic standpoint since it reprs an index into `TyAlias.predicates` but it's alright and it cleans up the usage sites of `TyAlias` 2. commit: fix an oversight: An empty leading where clause is still a leading where clause * semantically reject empty leading where clauses on lazy type aliases * e.g., on `#![feature(lazy_type_alias)] type X where = ();` * make empty leading where clauses on assoc types trigger lint `deprecated_where_clause_location` * e.g., `impl Trait for () { type X where = (); }`
2024-02-29AST: Refactor type alias where clausesLeón Orell Valerian Liehr-6/+11
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-28Rename `DiagnosticBuilder` as `Diag`.Nicholas Nethercote-45/+30
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-150/+191
2024-02-25Add `ast::ExprKind::Dummy`Lieselotte-2/+3
2024-02-25Rollup merge of #121060 - clubby789:bool-newtypes, r=cjgillotMatthias Krüger-105/+136
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-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/+15
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-34/+42
2024-02-19Prefer `DiagnosticBuilder` over `Diagnostic` in diagnostic modifiers.Nicholas Nethercote-13/+11
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-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-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-3/+3
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-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-08Continue to borrowck even if there were previous errorsOli Scherer-1/+11
2024-02-06Auto merge of #120392 - compiler-errors:async-bound-modifier, r=davidtwco,fmeasebors-7/+24
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-02Remove unnecessary `.to_string()`/`.as_str()`strevyn-3/+3
2024-01-31Better error message in ed 2015Michael Goulet-2/+13
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`