about summary refs log tree commit diff
path: root/compiler/rustc_parse/src
AgeCommit message (Collapse)AuthorLines
2025-02-28Tweak invalid RTN errorsEsteban Küber-2/+6
Make suggestions verbose. When encountering `method(type)` bound, suggest `method(..)` instead of `method()`. ``` error: argument types not allowed with return type notation --> $DIR/bad-inputs-and-output.rs:9:23 | LL | fn foo<T: Trait<method(i32): Send>>() {} | ^^^^^ | help: remove the input types | LL - fn foo<T: Trait<method(i32): Send>>() {} LL + fn foo<T: Trait<method(..): Send>>() {} | ``` When encountering both return type and arg list that isn't `..`, suggest replacing both. ``` error: return type not allowed with return type notation --> $DIR/bad-inputs-and-output.rs:12:25 | LL | fn bar<T: Trait<method() -> (): Send>>() {} | ^^^^^^ | help: use the right argument notation and remove the return type | LL - fn bar<T: Trait<method() -> (): Send>>() {} LL + fn bar<T: Trait<method(..): Send>>() {} | ``` When encountering a return type, suggest removing it including the leading whitespace. ``` error: return type not allowed with return type notation --> $DIR/bad-inputs-and-output.rs:24:45 | LL | fn bay_path<T: Trait>() where T::method(..) -> (): Send {} | ^^^^^ | help: remove the return type | LL - fn bay_path<T: Trait>() where T::method(..) -> (): Send {} LL + fn bay_path<T: Trait>() where T::method(..): Send {} | ```
2025-02-28Remove `NtPath`.Nicholas Nethercote-12/+19
2025-02-28Remove `NtMeta`.Nicholas Nethercote-22/+30
Note: there was an existing code path involving `Interpolated` in `MetaItem::from_tokens` that was dead. This commit transfers that to the new form, but puts an `unreachable!` call inside it.
2025-02-28Remove `NtPat`.Nicholas Nethercote-72/+53
The one notable test change is `tests/ui/macros/trace_faulty_macros.rs`. This commit removes the complicated `Interpolated` handling in `expected_expression_found` that results in a longer error message. But I think the new, shorter message is actually an improvement. The original complaint was in #71039, when the error message started with "error: expected expression, found `1 + 1`". That was confusing because `1 + 1` is an expression. Other than that, the reporter said "the whole error message is not too bad if you ignore the first line". Subsequently, extra complexity and wording was added to the error message. But I don't think the extra wording actually helps all that much. In particular, it still says of the `1+1` that "this is expected to be expression". This repeats the problem from the original complaint! This commit removes the extra complexity, reverting to a simpler error message. This is primarily because the traversal is a pain without `Interpolated` tokens. Nonetheless, I think the error message is *improved*. It now starts with "expected expression, found `pat` metavariable", which is much clearer and the real problem. It also doesn't say anything specific about `1+1`, which is good, because the `1+1` isn't really relevant to the error -- it's the `$e:pat` that's important.
2025-02-27Rollup merge of #136846 - nnethercote:make-AssocOp-more-like-ExprKind, ↵Matthias Krüger-80/+50
r=spastorino Make `AssocOp` more like `ExprKind` This is step 1 of [MCP 831](https://github.com/rust-lang/compiler-team/issues/831). r? ``@estebank``
2025-02-27Rename `AssocOp::As` as `AssocOp::Cast`.Nicholas Nethercote-2/+2
To match `ExprKind::Cast`, and because a semantic name makes more sense here than a syntactic name.
2025-02-27Replace `AssocOp::DotDot{,Eq}` with `AssocOp::Range`.Nicholas Nethercote-9/+6
It makes `AssocOp` more similar to `ExprKind` and makes things a little simpler. And the semantic names make more sense here than the syntactic names.
2025-02-27Introduce `AssocOp::Binary`.Nicholas Nethercote-56/+41
It mirrors `ExprKind::Binary`, and contains a `BinOpKind`. This makes `AssocOp` more like `ExprKind`. Note that the variants removed from `AssocOp` are all named differently to `BinOpToken`, e.g. `Multiply` instead of `Mul`, so that's an inconsistency removed. The commit adds `precedence` and `fixity` methods to `BinOpKind`, and calls them from the corresponding methods in `AssocOp`. This avoids the need to create an `AssocOp` from a `BinOpKind` in a bunch of places, and `AssocOp::from_ast_binop` is removed. `AssocOp::to_ast_binop` is also no longer needed. Overall things are shorter and nicer.
2025-02-27In `AssocOp::AssignOp`, use `BinOpKind` instead of `BinOpToken`Nicholas Nethercote-14/+2
`AssocOp::AssignOp` contains a `BinOpToken`. `ExprKind::AssignOp` contains a `BinOpKind`. Given that `AssocOp` is basically a cut-down version of `ExprKind`, it makes sense to make `AssocOp` more like `ExprKind`. Especially given that `AssocOp` and `BinOpKind` use semantic operation names (e.g. `Mul`, `Div`), but `BinOpToken` uses syntactic names (e.g. `Star`, `Slash`). This results in more concise code, and removes the need for various conversions. (Note that the removed functions `hirbinop2assignop` and `astbinop2assignop` are semantically identical, because `hir::BinOp` is just a synonum for `ast::BinOp`!) The only downside to this is that it allows the possibility of some nonsensical combinations, such as `AssocOp::AssignOp(BinOpKind::Lt)`. But `ExprKind::AssignOp` already has that problem. The problem can be fixed for both types in the future with some effort, by introducing an `AssignOpKind` type.
2025-02-25Teach structured errors to display short `Ty`Esteban Küber-1/+0
Make it so that every structured error annotated with `#[derive(Diagnostic)]` that has a field of type `Ty<'_>`, the printing of that value into a `String` will look at the thread-local storage `TyCtxt` in order to shorten to a length appropriate with the terminal width. When this happen, the resulting error will have a note with the file where the full type name was written to. ``` error[E0618]: expected function, found `((..., ..., ..., ...), ..., ..., ...)`` --> long.rs:7:5 | 6 | fn foo(x: D) { //~ `x` has type `(... | - `x` has type `((..., ..., ..., ...), ..., ..., ...)` 7 | x(); //~ ERROR expected function, found `(... | ^-- | | | call expression requires function | = note: the full name for the type has been written to 'long.long-type-14182675702747116984.txt' = note: consider using `--verbose` to print the full type name to the console ```
2025-02-23Rollup merge of #137435 - estebank:match-arm-2, r=compiler-errorsJacob Pratt-1/+2
Fix "missing match arm body" suggestion involving `!` Include the match arm guard in the gated span, so that the suggestion to add a body is correct instead of inserting the body before the guard. Make the suggestion verbose. ``` error: `match` arm with no body --> $DIR/feature-gate-never_patterns.rs:43:9 | LL | Some(_) if false, | ^^^^^^^^^^^^^^^^ | help: add a body after the pattern | LL | Some(_) if false => { todo!() }, | ++++++++++++++ ``` r? `@compiler-errors`
2025-02-23not lint break with label and unsafe blockMu001999-6/+8
2025-02-22Greatly simplify lifetime captures in edition 2024Michael Goulet-1/+1
2025-02-22Fix "missing match arm body" suggestion involving `!`Esteban Küber-1/+2
Include the match arm guard in the gated span, so that the suggestion to add a body is correct instead of inserting the body before the guard. Make the suggestion verbose. ``` error: `match` arm with no body --> $DIR/feature-gate-never_patterns.rs:43:9 | LL | Some(_) if false, | ^^^^^^^^^^^^^^^^ | help: add a body after the pattern | LL | Some(_) if false => { todo!() }, | ++++++++++++++ ```
2025-02-22Auto merge of #133436 - nnethercote:rm-NtVis-NtTy, r=petrochenkovbors-31/+100
Remove `NtVis` and `NtTy` The next part of #124141. The first actual remove of `Nonterminal` variants. `NtVis` is a simple case that doesn't get much use, but `NtTy` is more complex. r? `@petrochenkov`
2025-02-21Avoid snapshotting the parser in `parse_path_inner`.Nicholas Nethercote-18/+15
2025-02-21Remove `NtTy`.Nicholas Nethercote-20/+51
Notes about tests: - tests/ui/parser/macro/trait-object-macro-matcher.rs: the syntax error is duplicated, because it occurs now when parsing the decl macro input, and also when parsing the expanded decl macro. But this won't show up for normal users due to error de-duplication. - tests/ui/associated-consts/issue-93835.rs: similar, plus there are some additional errors about this very broken code. - The changes to metavariable descriptions in #132629 are now visible in error message for several tests.
2025-02-21Remove `NtVis`.Nicholas Nethercote-9/+50
We now use invisible delimiters for expanded `vis` fragments, instead of `Token::Interpolated`.
2025-02-20Rollup merge of #137281 - estebank:doc-comment-syntax-error, r=compiler-errorsMatthias Krüger-7/+9
Tweak "expected ident" parse error to avoid talking about doc comments When encountering a doc comment without an identifier after, we'd unconditionally state "this doc comment doesn't document anything", swallowing the *actual* error which is that the thing *after* the doc comment wasn't expected. Added a check that the found token is something that "conceptually" closes the previous item before emitting that error, otherwise just complain about the missing identifier. In both of the following cases, the syntax error follows a doc comment: ``` error: expected identifier, found keyword `Self` --> $DIR/doc-before-bad-variant.rs:4:5 | LL | enum TestEnum { | -------- while parsing this enum ... LL | Self, | ^^^^ expected identifier, found keyword | = help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` ``` ``` error: expected identifier, found `<` --> $DIR/doc-before-syntax-error.rs:2:1 | LL | <> | ^ expected identifier ``` Fix #71982.
2025-02-19Tweak "expected ident" parse error to avoid talking about doc commentsEsteban Küber-7/+9
When encountering a doc comment without an identifier after, we'd unconditionally state "this doc comment doesn't document anything", swallowing the *actual* error which is that the thing *after* the doc comment wasn't expected. Added a check that the found token is something that "conceptually" closes the previous item before emitting that error, otherwise just complain about the missing identifier. In both of the following cases, the syntax error follows a doc comment: ``` error: expected identifier, found keyword `Self` --> $DIR/doc-before-bad-variant.rs:4:5 | LL | enum TestEnum { | -------- while parsing this enum ... LL | Self, | ^^^^ expected identifier, found keyword | = help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }` ``` ``` error: expected identifier, found `<` --> $DIR/doc-before-syntax-error.rs:2:1 | LL | <> | ^ expected identifier ``` Fix #71982.
2025-02-16Fix const items not being allowed to be called `r#move` or `r#static`Noratrieb-3/+3
Because of an ambiguity with const closures, the parser needs to ensure that for a const item, the `const` keyword isn't followed by a `move` or `static` keyword, as that would indicate a const closure: ```rust fn main() { const move // ... } ``` This check did not take raw identifiers into account, therefore being unable to distinguish between `const move` and `const r#move`. The latter is obviously not a const closure, so it should be allowed as a const item. This fixes the check in the parser to only treat `const ...` as a const closure if it's followed by the *proper keyword*, and not a raw identifier. Additionally, this adds a large test that tests for all raw identifiers in all kinds of positions, including `const`, to prevent issues like this one from occurring again.
2025-02-15Rollup merge of #136808 - chenyukang:yukang-fix-arg-list-error-129273, ↵Matthias Krüger-13/+13
r=estebank Try to recover from path sep error in type parsing Fixes #129273 Error using `:` in the argument list may mess up the parser. case `tests/ui/suggestions/struct-field-type-including-single-colon` also changed, seems it's the same meaning, should be OK. r? `@estebank`
2025-02-15Rollup merge of #136490 - Skepfyr:no-field-rest-pattern-attrs, r=compiler-errorsMatthias Krüger-11/+11
Do not allow attributes on struct field rest patterns Fixes #81282. This removes support for attributes on struct field rest patterns (the `..` bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt. This needs an equivalent change to the reference but I wanted to see how this PR is received first. The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler. While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to *add* support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).
2025-02-15Try to recover from path sep error in parseryukang-13/+13
2025-02-10Stop using span hack for contracts feature gatingMichael Goulet-12/+2
2025-02-08Rustfmtbjorn3-103/+129
2025-02-07Rollup merge of #136191 - klensy:const_a, r=compiler-errorsMatthias Krüger-1/+1
compiler: replace few consts arrays with statics to remove const dupes Locally on `x86_64-pc-windows-msvc` -100kb for `rustc_driver.dll`
2025-02-06Stop passing the same resource multiple times when building ParseSessbjorn3-5/+3
2025-02-06Auto merge of #136471 - safinaskar:parallel, r=SparrowLiibors-12/+12
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc` This is continuation of https://github.com/rust-lang/rust/pull/132282 . I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement. There are other possibilities, through. We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase. So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge. cc "Parallel Rustc Front-end" ( https://github.com/rust-lang/rust/issues/113349 ) r? SparrowLii `@rustbot` label WG-compiler-parallel
2025-02-03Rename rustc_contract to contractCelina G. Val-14/+14
This has now been approved as a language feature and no longer needs a `rustc_` prefix. Also change the `contracts` feature to be marked as incomplete and `contracts_internals` as internal.
2025-02-03Separate contract feature gates for the internal machineryFelix S. Klock II-3/+17
The extended syntax for function signature that includes contract clauses should never be user exposed versus the interface we want to ship externally eventually.
2025-02-03Express contracts as part of function header and lower it to the contract ↵Celina G. Val-4/+39
lang items includes post-developed commit: do not suggest internal-only keywords as corrections to parse failures. includes post-developed commit: removed tabs that creeped in into rustfmt tool source code. includes post-developed commit, placating rustfmt self dogfooding. includes post-developed commit: add backquotes to prevent markdown checking from trying to treat an attr as a markdown hyperlink/ includes post-developed commit: fix lowering to keep contracts from being erroneously inherited by nested bodies (like closures). Rebase Conflicts: - compiler/rustc_parse/src/parser/diagnostics.rs - compiler/rustc_parse/src/parser/item.rs - compiler/rustc_span/src/hygiene.rs Remove contracts keywords from diagnostic messages
2025-02-03Do not allow attributes on struct field rest patternsJack Rickard-11/+11
This removes support for attributes on struct field rest patterns (the `..`) from the parser. Previously they were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
2025-02-03tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`Askar Safin-12/+12
2025-01-30Rollup merge of #135882 - hkBst:master, r=estebankMatthias Krüger-7/+4
simplify `similar_tokens` from `Option<Vec<_>>` to `&[_]` All uses immediately invoke contains, so maybe a further simplification is possible.
2025-01-28replaces few consts with statics to reduce readonly sectionklensy-1/+1
2025-01-28Rollup merge of #133151 - tyrone-wu:trim-fn-ptr-whitespace, r=compiler-errorsMatthias Krüger-6/+50
Trim extra whitespace in fn ptr suggestion span Trim extra whitespace when suggesting removal of invalid qualifiers when parsing function pointer type. Fixes: #133083 --- I made a comment about the format of the diagnostic error message in https://github.com/rust-lang/rust/issues/133083#issuecomment-2480047875. I think the `.label` may be a little redundant if the diagnostic only highlights the bad qualifier instead of the entire `TyKind::BareFn` span. If it makes sense, I can include it in this PR.
2025-01-27Trim extra whitespace in fn ptr suggestion spanTyrone Wu-6/+50
Trim extra whitespace when suggesting removal of invalid qualifiers when parsing function pointer type. Fixes: #133083 Signed-off-by: Tyrone Wu <wudevelops@gmail.com>
2025-01-27Use identifiers in diagnostics more oftenMichael Goulet-2/+2
2025-01-24use `fmt::from_fn` in more places, instead of using structs that impl ↵Yotam Ofek-35/+25
formatting traits
2025-01-24Rollup merge of #135855 - cuviper:parser-size, r=wesleywiserMatthias Krüger-2/+3
Only assert the `Parser` size on specific arches The size of this struct depends on the alignment of `u128`, for example powerpc64le and s390x have align-8 and end up with only 280 bytes. Our 64-bit tier-1 arches are the same though, so let's just assert on those. r? nnethercote
2025-01-23simplify similar_tokens from Vec<_> to &[_]Marijn Schouten-2/+2
2025-01-23simplify similar_tokens from Option<Vec<_>> to Vec<_>Marijn Schouten-6/+3
2025-01-22Rollup merge of #135557 - estebank:wtf8, r=fee1-deadMatthias Krüger-4/+63
Point at invalid utf-8 span on user's source code ``` error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8 --> $DIR/not-utf8-2.rs:6:5 | LL | include!("not-utf8-bin-file.rs"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: byte `193` is not valid utf-8 --> $DIR/not-utf8-bin-file.rs:2:14 | LL | let _ = "�|�␂!5�cc␕␂��"; | ^ = note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info) ``` When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character. Fix #76869.
2025-01-22Auto merge of #134478 - compiler-errors:attr-span, r=oli-obkbors-6/+2
Properly record metavar spans for other expansions other than TT This properly records metavar spans for nonterminals other than tokentree. This means that we operations like `span.to(other_span)` work correctly for macros. As you can see, other diagnostics involving metavars have improved as a result. Fixes #132908 Alternative to #133270 cc `@ehuss` cc `@petrochenkov`
2025-01-21Only assert the `Parser` size on specific archesJosh Stone-2/+3
The size of this struct depends on the alignment of `u128`, for example powerpc64le and s390x have align-8 and end up with only 280 bytes. Our 64-bit tier-1 arches are the same though, so let's just assert on those.
2025-01-22Point at invalid utf-8 span on user's source codeEsteban Küber-4/+63
``` error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8 --> $DIR/not-utf8-2.rs:6:5 | LL | include!("not-utf8-bin-file.rs"); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | note: `[193]` is not valid utf-8 --> $DIR/not-utf8-bin-file.rs:2:14 | LL | let _ = "�|�␂!5�cc␕␂��"; | ^ = note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info) ``` When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character. Fix #76869.
2025-01-19Run `clippy --fix` for `unnecessary_map_or` lintYotam Ofek-1/+1
2025-01-11Remove allocations from case-insensitive comparison to keywordsMark Rousskov-2/+3
2025-01-09Auto merge of #135268 - pietroalbini:pa-bump-stage0, r=Mark-Simulacrumbors-2/+2
Master bootstrap update Part of the release process. r? `@Mark-Simulacrum`
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-10 19:51:11 +0000