summary refs log tree commit diff
path: root/tests/ui/parser
AgeCommit message (Collapse)AuthorLines
2024-11-17Diagnostics for let mut in item contextKornel-1/+22
2024-11-17Rollup merge of #133060 - tyrone-wu:removelet-span-suggestion, r=jieyouxu许杰友 Jieyou Xu (Joe)-13/+28
Trim whitespace in RemoveLet primary span Separate `RemoveLet` span into primary span for `let` and removal suggestion span for `let `, so that primary span does not include whitespace. Fixes: #133031
2024-11-16Reword suggestion messageEsteban Küber-17/+17
2024-11-16Better account for `else if` macro conditions mising an `if`Esteban Küber-1/+8
If a macro statement has been parsed after `else`, suggest a missing `if`: ``` error: expected `{`, found `falsy` --> $DIR/else-no-if.rs:47:12 | LL | } else falsy! {} { | ---- ^^^^^ | | | expected an `if` or a block after this `else` | help: add an `if` if this is the condition of a chained `else if` statement | LL | } else if falsy! {} { | ++ ```
2024-11-16Increase accuracy of `if` condition misparse suggestionEsteban Küber-5/+293
Look at the expression that was parsed when trying to recover from a bad `if` condition to determine what was likely intended by the user beyond "maybe this was meant to be an `else` body". ``` error: expected `{`, found `map` --> $DIR/missing-dot-on-if-condition-expression-fixable.rs:4:30 | LL | for _ in [1, 2, 3].iter()map(|x| x) {} | ^^^ expected `{` | help: you might have meant to write a method call | LL | for _ in [1, 2, 3].iter().map(|x| x) {} | + ```
2024-11-15Trim whitespace in RemoveLet primary spanTyrone Wu-13/+28
Separate `RemoveLet` span into primary span for `let` and removal suggestion span for `let `, so that primary span does not include whitespace. Fixes: #133031 Signed-off-by: Tyrone Wu <wudevelops@gmail.com>
2024-11-13Trim extra space when suggesting removing bad `let`clubby789-4/+4
2024-11-11Auto merge of #126597 - estebank:unicode-output, r=fmeasebors-1/+1
Add Unicode block-drawing compiler output support Add nightly-only theming support to rustc output using Unicode box drawing characters instead of ASCII-art to draw the terminal UI. In order to enable, the flags `-Zunstable-options=yes --error-format=human-unicode` must be passed in. After: ``` error: foo ╭▸ test.rs:3:3 │ 3 │ X0 Y0 Z0 │ ┌───╿──│──┘ │ ┌│───│──┘ │ ┏││━━━┙ │ ┃││ 4 │ ┃││ X1 Y1 Z1 5 │ ┃││ X2 Y2 Z2 │ ┃│└────╿──│──┘ `Z` label │ ┃└─────│──┤ │ ┗━━━━━━┥ `Y` is a good letter too │ `X` is a good letter ╰╴ note: bar ╭▸ test.rs:4:3 │ 4 │ ┏ X1 Y1 Z1 5 │ ┃ X2 Y2 Z2 6 │ ┃ X3 Y3 Z3 │ ┗━━━━━━━━━━┛ ├ note: bar ╰ note: baz note: qux ╭▸ test.rs:4:3 │ 4 │ X1 Y1 Z1 ╰╴ ━━━━━━━━ ``` Before: ``` error: foo --> test.rs:3:3 | 3 | X0 Y0 Z0 | ___^__-__- | |___|__| | ||___| | ||| 4 | ||| X1 Y1 Z1 5 | ||| X2 Y2 Z2 | |||____^__-__- `Z` label | ||_____|__| | |______| `Y` is a good letter too | `X` is a good letter | note: bar --> test.rs:4:3 | 4 | / X1 Y1 Z1 5 | | X2 Y2 Z2 6 | | X3 Y3 Z3 | |__________^ = note: bar = note: baz note: qux --> test.rs:4:3 | 4 | X1 Y1 Z1 | ^^^^^^^^ ``` After: ![rustc output with unicode box drawing characters](https://github.com/rust-lang/rust/assets/1606434/d210b79a-6579-4407-9706-ba8edc6e9f25) Before: ![current rustc output with ASCII art](https://github.com/rust-lang/rust/assets/1606434/5aecccf8-a6ee-4469-8b39-72fb0d979a9f)
2024-11-10Add Unicode block-drawing compiler output supportEsteban Küber-1/+1
Add nightly-only theming support to rustc output using Unicode box drawing characters instead of ASCII-art to draw the terminal UI: After: ``` error: foo ╭▸ test.rs:3:3 │ 3 │ X0 Y0 Z0 │ ┌───╿──│──┘ │ ┌│───│──┘ │ ┏││━━━┙ │ ┃││ 4 │ ┃││ X1 Y1 Z1 5 │ ┃││ X2 Y2 Z2 │ ┃│└────╿──│──┘ `Z` label │ ┃└─────│──┤ │ ┗━━━━━━┥ `Y` is a good letter too │ `X` is a good letter ╰╴ note: bar ╭▸ test.rs:4:3 │ 4 │ ┏ X1 Y1 Z1 5 │ ┃ X2 Y2 Z2 6 │ ┃ X3 Y3 Z3 │ ┗━━━━━━━━━━┛ ├ note: bar ╰ note: baz note: qux ╭▸ test.rs:4:3 │ 4 │ X1 Y1 Z1 ╰╴ ━━━━━━━━ ``` Before: ``` error: foo --> test.rs:3:3 | 3 | X0 Y0 Z0 | ___^__-__- | |___|__| | ||___| | ||| 4 | ||| X1 Y1 Z1 5 | ||| X2 Y2 Z2 | |||____^__-__- `Z` label | ||_____|__| | |______| `Y` is a good letter too | `X` is a good letter | note: bar --> test.rs:4:3 | 4 | / X1 Y1 Z1 5 | | X2 Y2 Z2 6 | | X3 Y3 Z3 | |__________^ = note: bar = note: baz note: qux --> test.rs:4:3 | 4 | X1 Y1 Z1 | ^^^^^^^^ ```
2024-11-03Yeet effects featureMichael Goulet-2/+1
2024-10-30Annotate `input` reference testsEric Huss-28/+42
2024-10-30Rollup merge of #132332 - nnethercote:use-token_descr-more, r=estebankMatthias Krüger-12/+12
Use `token_descr` more in error messages This is the first two commits from #124141, put into their own PR to get things rolling. Commit messages have the details. r? ``@estebank`` cc ``@petrochenkov``
2024-10-29Remove detail from label/note that is already available in other noteEsteban Küber-1/+1
Remove the "which is required by `{root_obligation}`" post-script in "the trait `X` is not implemented for `Y`" explanation in E0277. This information is already conveyed in the notes explaining requirements, making it redundant while making the text (particularly in labels) harder to read. ``` error[E0277]: the trait bound `NotCopy: Copy` is not satisfied --> $DIR/wf-static-type.rs:10:13 | LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None }; | ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy` | = note: required for `Option<NotCopy>` to implement `Copy` note: required by a bound in `IsCopy` --> $DIR/wf-static-type.rs:7:17 | LL | struct IsCopy<T:Copy> { t: T } | ^^^^ required by this bound in `IsCopy` ``` vs the prior ``` error[E0277]: the trait bound `NotCopy: Copy` is not satisfied --> $DIR/wf-static-type.rs:10:13 | LL | static FOO: IsCopy<Option<NotCopy>> = IsCopy { t: None }; | ^^^^^^^^^^^^^^^^^^^^^^^ the trait `Copy` is not implemented for `NotCopy`, which is required by `Option<NotCopy>: Copy` | = note: required for `Option<NotCopy>` to implement `Copy` note: required by a bound in `IsCopy` --> $DIR/wf-static-type.rs:7:17 | LL | struct IsCopy<T:Copy> { t: T } | ^^^^ required by this bound in `IsCopy` ```
2024-10-28Tweak more warnings.Nicholas Nethercote-4/+4
Much like the previous commit. I think the removal of "the token" in each message is fine here. There are many more error messages that mention tokens without saying "the token" than those that do say it.
2024-10-28Tweak `expand_incomplete_parse` warning.Nicholas Nethercote-8/+8
By using `token_descr`, as is done for many other errors, we can get slightly better descriptions in error messages, e.g. "macro expansion ignores token `let` and any following" becomes "macro expansion ignores keyword `let` and any tokens following". This will be more important once invisible delimiters start being mentioned in error messages -- without this commit, that leads to error messages such as "error at ``" because invisible delimiters are pretty printed as an empty string.
2024-10-26Deny calls to non-`#[const_trait]` methods in MIR constckDeadbeef-4/+0
2024-10-14Rollup merge of #131550 - compiler-errors:extern-diags, r=spastorinoMatthias Krüger-30/+30
Make some tweaks to extern block diagnostics Self-explanatory. See the diagnostic changes; I hope they make them a bit more descriptive. r? spastorino
2024-10-12Rollup merge of #130870 - surechen:fix_130791, r=compiler-errorsTrevor Gross-0/+28
Add suggestion for removing invalid path sep `::` in fn def Add suggestion for removing invalid path separator `::` in function definition. for example: `fn invalid_path_separator::<T>() {}` fixes #130791
2024-10-11Note what qualifierMichael Goulet-24/+24
2024-10-11Remove unadornedMichael Goulet-9/+9
2024-10-06On function and method calls in patterns, link to the bookEsteban Küber-58/+129
``` error: expected a pattern, found an expression --> f889.rs:3:13 | 3 | let (x, y.drop()) = (1, 2); //~ ERROR | ^^^^^^^^ not a pattern | = note: arbitrary expressions are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html> error[E0532]: expected a pattern, found a function call --> f889.rs:2:13 | 2 | let (x, drop(y)) = (1, 2); //~ ERROR | ^^^^ not a tuple struct or tuple variant | = note: function calls are not allowed in patterns: <https://doc.rust-lang.org/book/ch18-00-patterns.html> ``` Fix #97200.
2024-09-27Add suggestion for removing invalid path separator `::` in function definition.surechen-0/+28
for example: `fn invalid_path_separator::<T>() {}` fixes: #130791
2024-09-25Compiler: Rename "object safe" to "dyn compatible"León Orell Valerian Liehr-3/+3
2024-09-22Add more test cases for block-no-opening-bracePavel Grigorenko-12/+48
2024-09-22Auto merge of #130246 - dianne:issue-97589-fix, r=petrochenkovbors-0/+20
rustc_expand: remember module `#[path]`s during expansion During invocation collection, if a module item parsed from a `#[path]` attribute needed a second pass after parsing, its path wouldn't get added to the file path stack, so cycle detection broke. This checks the `#[path]` in such cases, so that it gets added appropriately. I think it should work identically to the case for external modules that don't need a second pass, but I'm not 100% sure. Fixes #97589
2024-09-21Parser: recover from `:::` to `::` in delegationsPavel Grigorenko-0/+126
2024-09-21Parser: recover from `:::` to `::`Pavel Grigorenko-0/+192
2024-09-18Add suggestions for expressions in patternsLieselotte-55/+781
2024-09-18Recover more expressions in patternsLieselotte-213/+543
2024-09-18Rollup merge of #130116 - veera-sivarajan:freeze-suggestions, r=chenyukangMatthias Krüger-16/+0
Implement a Method to Seal `DiagInner`'s Suggestions This PR adds a method on `DiagInner` called `.seal_suggestions()` to prevent new suggestions from being added while preserving existing suggestions. This is useful because currently there is no way to prevent new suggestions from being added to a diagnostic. `.disable_suggestions()` is the closest but it gets rid of all suggestions before and after the call. Therefore, `.seal_suggestions()` can be used when, for example, misspelled keyword is detected and reported. In such cases, we may want to prevent other suggestions from being added to the diagnostic, as they would likely be meaningless once the misspelled keyword is identified. For context: https://github.com/rust-lang/rust/pull/129899#discussion_r1741307132 To store an additional state, the type of the `suggestions` field in `DiagInner` was changed into a three variant enum. While this change affects files across different crates, care was taken to preserve the existing code's semantics. This is validated by the fact that all UI tests pass without any modifications. r? chenyukang
2024-09-14stabilize `const_extern_fn`Folkert de Vries-19/+17
2024-09-12Implement a Method to Seal `DiagInner`'s SuggestionsVeera-16/+0
2024-09-11add regression test for #97589dianne-0/+20
2024-09-11Rollup merge of #129520 - tunawasabi:suggest-adding-struct-pattern-syntax, ↵Matthias Krüger-0/+5
r=compiler-errors Suggest the correct pattern syntax on usage of unit variant pattern for a struct variant Closes #126243 I add a suggestion on usage of unit variant pattern for a struct variant.
2024-09-06Add Suggestions for Misspelled KeywordsVeera-13/+169
This PR detects misspelled keywords using two heuristics: 1. Lowercasing the unexpected identifier. 2. Using edit distance to find a keyword similar to the unexpected identifier. However, it does not detect each and every misspelled keyword to minimize false positives and ambiguities. More details about the implementation can be found in the comments.
2024-09-02Update TestsVeera-0/+409
2024-08-28Suggest the struct variant pattern syntax on usage of unit variant pattern ↵tunawasabi-0/+5
for a struct variant
2024-08-24Rollup merge of #128524 - ↵Trevor Gross-36/+28
chenyukang:yukang-fix-127930-invalid-outer-style-sugg, r=cjgillot Don't suggest turning crate-level attributes into outer style Fixes #127930
2024-08-09tests: add regression test for #128845许杰友 Jieyou Xu (Joe)-0/+42
For codepoint boundary assertion triggered by a let stmt compound assignment removal suggestion when encountering recovered multi-byte compound ops. Issue: <https://github.com/rust-lang/rust/issues/128845>
2024-08-03Rollup merge of #127921 - spastorino:stabilize-unsafe-extern-blocks, ↵Matthias Krüger-34/+4
r=compiler-errors Stabilize unsafe extern blocks (RFC 3484) # Stabilization report ## Summary This is a tracking issue for the RFC 3484: Unsafe Extern Blocks We are stabilizing `#![feature(unsafe_extern_blocks)]`, as described in [Unsafe Extern Blocks RFC 3484](https://github.com/rust-lang/rfcs/pull/3484). This feature makes explicit that declaring an extern block is unsafe. Starting in Rust 2024, all extern blocks must be marked as unsafe. In all editions, items within unsafe extern blocks may be marked as safe to use. RFC: https://github.com/rust-lang/rfcs/pull/3484 Tracking issue: #123743 ## What is stabilized ### Summary of stabilization We now need extern blocks to be marked as unsafe and items inside can also have safety modifiers (unsafe or safe), by default items with no modifiers are unsafe to offer easy migration without surprising results. ```rust unsafe extern { // sqrt (from libm) may be called with any `f64` pub safe fn sqrt(x: f64) -> f64; // strlen (from libc) requires a valid pointer, // so we mark it as being an unsafe fn pub unsafe fn strlen(p: *const c_char) -> usize; // this function doesn't say safe or unsafe, so it defaults to unsafe pub fn free(p: *mut core::ffi::c_void); pub safe static IMPORTANT_BYTES: [u8; 256]; pub safe static LINES: SyncUnsafeCell<i32>; } ``` ## Tests The relevant tests are in `tests/ui/rust-2024/unsafe-extern-blocks`. ## History - https://github.com/rust-lang/rust/pull/124482 - https://github.com/rust-lang/rust/pull/124455 - https://github.com/rust-lang/rust/pull/125077 - https://github.com/rust-lang/rust/pull/125522 - https://github.com/rust-lang/rust/issues/126738 - https://github.com/rust-lang/rust/issues/126749 - https://github.com/rust-lang/rust/issues/126755 - https://github.com/rust-lang/rust/pull/126757 - https://github.com/rust-lang/rust/pull/126758 - https://github.com/rust-lang/rust/issues/126756 - https://github.com/rust-lang/rust/pull/126973 - https://github.com/rust-lang/rust/pull/127535 - https://github.com/rust-lang/rustfmt/pull/6204 ## Unresolved questions I am not aware of any unresolved questions.
2024-08-04don't suggest turning crate-level attributes into outer styleyukang-36/+28
2024-08-03Revert "Rollup merge of #125572 - mu001999-contrib:dead/enhance, r=pnkfelix"Michael Goulet-9/+7
This reverts commit 13314df21b0bb0cdd02c6760581d1b9f1052fa7e, reversing changes made to 6e534c73c35f569492ed5fb5f349075d58ed8b7e.
2024-08-03Revert "Rollup merge of #127107 - mu001999-contrib:dead/enhance-2, r=pnkfelix"Michael Goulet-3/+1
This reverts commit 31fe9628cf830a08e7194a446f66c668aaea86e9, reversing changes made to f20307851ead9fbbb9fa88bbffb3258a069230a6.
2024-08-01Fix removed `box_syntax` diagnostic if source isn't availableclubby789-5/+5
2024-07-30Auto merge of #127955 - ↵bors-7/+37
chenyukang:yukang-fix-mismatched-delimiter-issue-12786, r=nnethercote Add limit for unclosed delimiters in lexer diagnostic Fixes #127868 The first commit shows the original diagnostic, and the second commit shows the changes.
2024-07-26Rollup merge of #128229 - tdittr:unsafe-extern-abi-error, r=compiler-errorsTrevor Gross-8/+41
Improve `extern "<abi>" unsafe fn()` error message These errors were already reported in #87217, and fixed by #87235 but missed the case of an explicit ABI. This PR does not cover multiple keywords like `extern "C" pub const unsafe fn()`, but I don't know what a good way to cover this would be. It also seems rarer than `extern "C" unsafe` which I saw happen a few times in workshops.
2024-07-26Improve error message for `extern "C" unsafe fn()`Tamme Dittrich-11/+24
This was handled correctly already for `extern unsafe fn()`. Co-authored-by: Folkert <folkert@folkertdev.nl>
2024-07-26Add a test case for `extern "C" unsafe` to the ui testsTamme Dittrich-0/+20
2024-07-25Support ?Trait bounds in supertraits and dyn Trait under a feature gateBryanskiy-4/+14
2024-07-25add limit for unclosed delimiters in lexer diagnosticyukang-29/+7
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-24 19:43:39 +0000