about summary refs log tree commit diff
path: root/tests/ui/suggestions
AgeCommit message (Collapse)AuthorLines
2025-07-18Rollup merge of #138554 - xizheyin:issue-138401, r=chenyukangMatthias Krüger-3/+1
Distinguish delim kind to decide whether to emit unexpected closing delimiter Fixes #138401
2025-07-18Deduplicate `unmatched_delims` in `rustc_parse` to reduce confusionxizheyin-3/+1
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-07-13Retire hir::*ItemRef.Camille GILLOT-1/+1
2025-07-11Rollup merge of #143661 - Muscraft:other-suggestion-message, r=estebankMatthias Krüger-2/+284
chore: Improve how the other suggestions message gets rendered Note: This change is part of my ongoing work to use `annotate-snippets` as `rustc`'s emitter This change started as a way to remove some specialty code paths from `annotate-snippets`, by making the "and {} other candidates" message get rendered like a secondary message with no level, but turned into a fix for the message's Unicode output. Before this change, when using the Unicode output, the other suggestions message would get rendered outside of the main suggestion block, making it feel disconnected from what it was referring to. This change makes it so that the message is on the last line of the block, aligning its rendering with other secondary messages, and making it clear what the message is referring to. Before: ``` error[E0433]: failed to resolve: use of undeclared type `IntoIter` ╭▸ $DIR/issue-82956.rs:28:24 │ LL │ let mut iter = IntoIter::new(self); │ ━━━━━━━━ use of undeclared type `IntoIter` ╰╴ help: consider importing one of these structs ╭╴ LL + use std::array::IntoIter; ├╴ LL + use std::collections::binary_heap::IntoIter; ├╴ LL + use std::collections::btree_map::IntoIter; ├╴ LL + use std::collections::btree_set::IntoIter; ╰╴ and 9 other candidates ``` After: ``` error[E0433]: failed to resolve: use of undeclared type `IntoIter` ╭▸ $DIR/issue-82956.rs:28:24 │ LL │ let mut iter = IntoIter::new(self); │ ━━━━━━━━ use of undeclared type `IntoIter` ╰╴ help: consider importing one of these structs ╭╴ LL + use std::array::IntoIter; ├╴ LL + use std::collections::binary_heap::IntoIter; ├╴ LL + use std::collections::btree_map::IntoIter; ├╴ LL + use std::collections::btree_set::IntoIter; │ ╰ and 9 other candidates ```
2025-07-10Update testEsteban Küber-14/+70
2025-07-10Make `Diag::multipart_suggestions` always verboseEsteban Küber-61/+101
2025-07-10Rework borrowing suggestions to use `Expr` instead of just `Span`Esteban Küber-60/+40
In the suggestion machinery for borrowing expressions and types, always use the available obligation `Span` to find the appropriate `Expr` to perform appropriateness checks no the `ExprKind` instead of on the textual snippet corresponding to the `Span`. Unify the logic for the case where `&` *and* `&mut` are appropriate with the logic for only one of those cases. Handle the case when `S::foo()` should have been `<&S>::foo()` (instead of suggesting the prior `&S::foo()`.
2025-07-10chore: Improve how the other suggestions message gets renderedScott Schafer-8/+8
2025-07-10test: Make one multi suggestion test unicodeScott Schafer-0/+282
2025-07-08Rollup merge of #143532 - compiler-errors:mut-ref-sugg, r=davidtwcoTrevor Gross-0/+34
More carefully consider span context when suggesting remove `&mut` Use `find_ancestor_inside` to compute a relative span that is macro-aware, rather than falling back to using BytePos arithmetic which is wrong for `&mut`. Fixes https://github.com/rust-lang/rust/issues/143523
2025-07-07Rollup merge of #132469 - estebank:issue-132041, r=NadrierilMatthias Krüger-0/+92
Do not suggest borrow that is already there in fully-qualified call When encountering `&str::from("value")` do not suggest `&&str::from("value")`. Fix #132041.
2025-07-06More carefully consider span context when suggesting remove &mutMichael Goulet-0/+34
2025-07-03Rework logic and provide structured suggestionEsteban Küber-3/+64
2025-07-01Do not suggest borrow that is already there in fully-qualified callEsteban Küber-0/+31
When encountering `&str::from("value")` do not suggest `&&str::from("value")`. Fix #132041.
2025-07-01Remove support for dyn*Michael Goulet-36/+5
2025-06-30Replace `ItemCtxt::report_placeholder_type_error` `match` with a call to ↵Guillaume Gomez-2/+2
`TyCtxt::def_descr`
2025-06-27Report infer ty errors during hir ty loweringOli Scherer-6/+0
This centralizes the placeholder type error reporting in one location, but it also exposes the granularity at which we convert things from hir to ty more. E.g. previously infer types in where bounds were errored together with the function signature, but now they are independent.
2025-06-26Rollup merge of #142981 - compiler-errors:verbose-missing-suggestion, r=estebankMatthias Krüger-3/+6
Make missing lifetime suggestion verbose I keep seeing this suggestion when working on rustc, and it's annoying that it's inline. Part of https://github.com/rust-lang/rust/issues/141973. Feel free to close this if there's another PR already doing this. r? ``@estebank``
2025-06-26Rollup merge of #139594 - compiler-errors:if-cause, r=oli-obkMatthias Krüger-6/+10
Simplify `ObligationCauseCode::IfExpression` This originally started out as an experiment to do less incremental invalidation by deferring the span operations that happen on the good path in `check_expr_if`, but it ended up not helping much (or at least not showing up in our incremental tests). As a side-effect though, I think the code is a lot cleaner and there are modest diagnostics improvements with overlapping spans, so I think it's still worth landing.
2025-06-26Simplify IfCauseMichael Goulet-6/+10
2025-06-24Make missing lifetime suggestion verboseMichael Goulet-3/+6
2025-06-24Suggest cloning `Arc` moved into closureEsteban Küber-1/+1
``` error[E0382]: borrow of moved value: `x` --> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20 | LL | let x = "Hello world!".to_string(); | - move occurs because `x` has type `String`, which does not implement the `Copy` trait LL | thread::spawn(move || { | ------- value moved into closure here LL | println!("{}", x); | - variable moved due to use in closure LL | }); LL | println!("{}", x); | ^ value borrowed here after move | = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info) help: consider cloning the value before moving it into the closure | LL ~ let value = x.clone(); LL ~ thread::spawn(move || { LL ~ println!("{}", value); | ```
2025-06-23compiletest: Improve diagnostics for line annotation mismatchesVadim Petrochenkov-2/+2
2025-06-22Rollup merge of #142594 - mejrs:new_desugaring, r=chenyukangGuillaume Gomez-37/+44
Add DesugaringKind::FormatLiteral Implements `DesugaringKind::FormatLiteral` to mark the FormatArgs desugaring of format literals. The main use for this is to stop yapping about about formatting parameters if we're not anywhere near a format literal. The other use case is to fix suggestions such as https://github.com/rust-lang/rust/issues/141350. It might also be useful for new or existing diagnostics that check whether they're in a format-like macro. cc `@xizheyin` `@fmease`
2025-06-22Rollup merge of #142458 - oli-obk:dyn-incompat, r=compiler-errorsGuillaume Gomez-118/+45
Merge unboxed trait object error suggestion into regular dyn incompat error Another hir-walker removed from the well-formed queries. This error was always a duplicate of another, but it was able to provide more information because it could invoke `is_dyn_compatible` without worrying about cycle errors. That's also the reason we can't put the error directly into hir_ty_lowering when lowering a `dyn Trait` within an associated item signature. So instead I packed it into the error handling of wf obligation checking.
2025-06-22Implement DesugaringKind::FormatLiteralmejrs-37/+44
2025-06-18Bless/update tests.Mara Bos-2/+10
2025-06-18Remove 'this error originates in format_args_nl' from test output.Mara Bos-8/+0
This message is no longer generated. This is probably a good thing. The relevant span is entirely in user code, and "format_args_nl" is an implementation detail with a name that isn't even public.
2025-06-13Merge unboxed trait object error suggestion into regular dyn incompat errorOli Scherer-118/+45
2025-06-12Rollup merge of #142066 - ferrocene:lw/edition-2015-tests, r=compiler-errorsMatthias Krüger-68/+76
More simple 2015 edition test decoupling This should be the last of these PRs for now. The remaining tests that do not work on other editions than 2015 either need the range support (so blocked on the MCP), need normalization rules (which needs discussions first/same MCP) or revisions. r? compiler-errors
2025-06-09Make E0621 missing lifetime suggestion verboseEsteban Küber-3/+5
``` error[E0621]: explicit lifetime required in the type of `x` --> $DIR/42701_one_named_and_one_anonymous.rs:10:9 | LL | &*x | ^^^ lifetime `'a` required | help: add explicit lifetime `'a` to the type of `x` | LL | fn foo2<'a>(a: &'a Foo, x: &'a i32) -> &'a i32 { | ++ ```
2025-06-09Auto merge of #142234 - matthiaskrgr:rollup-kg5wibu, r=matthiaskrgrbors-0/+31
Rollup of 6 pull requests Successful merges: - rust-lang/rust#141751 (Remap compiler vs non-compiler sources differently (bootstrap side)) - rust-lang/rust#142160 (Only allow `bootstrap` cfg in rustc & related) - rust-lang/rust#142191 (early return in trait detection for non-trait item) - rust-lang/rust#142211 (Do not checkout GCC submodule for the tidy job) - rust-lang/rust#142218 (CI: rfl: move job forward to Linux v6.16-rc1) - rust-lang/rust#142224 (Avoid a gratuitous 10s wait in a stress test) r? `@ghost` `@rustbot` modify labels: rollup
2025-06-09early return in trait detection for non-trait itembohan-0/+31
2025-06-08add (back) unsupported_calling_conventions lint to reject more invalid ↵Ralf Jung-10/+10
calling conventions
2025-06-05Auto merge of #138677 - shepmaster:consistent-elided-lifetime-syntax, ↵bors-20/+2
r=traviscross,jieyouxu Add a new `mismatched-lifetime-syntaxes` lint The lang-team [discussed this](https://hackmd.io/nf4ZUYd7Rp6rq-1svJZSaQ) and I attempted to [summarize](https://github.com/rust-lang/rust/pull/120808#issuecomment-2701863833) their decision. The summary-of-the-summary is: - Using two different kinds of syntax for elided lifetimes is confusing. In rare cases, it may even [lead to unsound code](https://github.com/rust-lang/rust/issues/48686)! Some examples: ```rust // Lint will warn about these fn(v: ContainsLifetime) -> ContainsLifetime<'_>; fn(&'static u8) -> &u8; ``` - Matching up references with no lifetime syntax, references with anonymous lifetime syntax, and paths with anonymous lifetime syntax is an exception to the simplest possible rule: ```rust // Lint will not warn about these fn(&u8) -> &'_ u8; fn(&'_ u8) -> &u8; fn(&u8) -> ContainsLifetime<'_>; ``` - Having a lint for consistent syntax of elided lifetimes will make the [future goal](https://github.com/rust-lang/rust/issues/91639) of warning-by-default for paths participating in elision much simpler. --- This new lint attempts to accomplish the goal of enforcing consistent syntax. In the process, it supersedes and replaces the existing `elided-named-lifetimes` lint, which means it starts out life as warn-by-default.
2025-06-05Add missing `dyn` keywords to tests that do not test for themLukas Wirth-40/+44
2025-06-05Add more missing 2015 edition directivesLukas Wirth-14/+18
2025-06-05Use non-2015 edition paths in tests that do not test for their resolutionLukas Wirth-14/+14
2025-06-04Replace `elided_named_lifetimes` with `mismatched_lifetime_syntaxes`Jake Goulding-20/+2
2025-06-03Add `iter` macroOli Scherer-1/+1
This adds an `iter!` macro that can be used to create movable generators. This also adds a yield_expr feature so the `yield` keyword can be used within iter! macro bodies. This was needed because several unstable features each need `yield` expressions, so this allows us to stabilize them separately from any individual feature. Co-authored-by: Oli Scherer <github35764891676564198441@oli-obk.de> Co-authored-by: Jieyou Xu <jieyouxu@outlook.com> Co-authored-by: Travis Cross <tc@traviscross.com>
2025-05-24Avoid extra path trimming in method not found errorNoratrieb-4/+4
Method errors have an extra check that force trim paths whenever the normal string is longer than 10 characters, which can be quite unhelpful when multiple items have the same name (for example an `Error`). A user reported this force trimming as being quite unhelpful when they had a method error where the precise path of the `Error` mattered. The code uses `tcx.short_string` already to get the normal path, which tries to be clever around trimming paths if necessary, so there is no reason for this extra force trimming.
2025-05-02Handle `Path<>` better in error messages.Nicholas Nethercote-10/+8
`Path<>` needs to be distinguished from `Path<T>`. This commit does that, improving some error messages.
2025-05-02Augment `impl-trait-missing-lifetime-gated.rs`.Nicholas Nethercote-5/+65
We have coverage for `Foo` and `Foo<T>` but not for `Foo<>`. This commit adds it. Note that the output has bogus syntax: `impl Foo'a, >`
2025-04-30compiletest: Make diagnostic kind mandatory on line annotationsVadim Petrochenkov-3/+5
2025-04-24Rollup merge of #140228 - fmease:revert-overzealous-colon-recovery, r=jieyouxuMatthias Krüger-75/+21
Revert overzealous parse recovery for single colons in paths Basically manually reverts #136808, cc ``@chenyukang`` ``@estebank.`` Reopens #129273. Fixes [after beta backport] #140227.
2025-04-24Revert overzealous parse recovery for single colonsLeón Orell Valerian Liehr-75/+21
2025-04-23rc and cr more clear error messageKivooeo-0/+31
2025-04-17Auto merge of #139949 - matthiaskrgr:rollup-pxc5tsx, r=matthiaskrgrbors-4/+4
Rollup of 8 pull requests Successful merges: - #138632 (Stabilize `cfg_boolean_literals`) - #139416 (unstable book; document `macro_metavar_expr_concat`) - #139782 (Consistent with treating Ctor Call as Struct in liveness analysis) - #139885 (document RUSTC_BOOTSTRAP, RUSTC_OVERRIDE_VERSION_STRING, and -Z allow-features in the unstable book) - #139904 (Explicitly annotate edition for `unpretty=expanded` and `unpretty=hir` tests) - #139932 (transmutability: Refactor tests for simplicity) - #139944 (Move eager translation to a method on Diag) - #139948 (git: ignore `60600a6fa403216bfd66e04f948b1822f6450af7` for blame purposes) r? `@ghost` `@rustbot` modify labels: rollup
2025-04-17Rollup merge of #138632 - clubby789:stabilize-cfg-boolean-lit, ↵Matthias Krüger-4/+4
r=davidtwco,Urgau,traviscross Stabilize `cfg_boolean_literals` Closes #131204 `@rustbot` labels +T-lang +I-lang-nominated This will end up conflicting with the test in #138293 so whichever doesn't land first will need updating -- # Stabilization Report ## General design ### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized? [RFC 3695](https://github.com/rust-lang/rfcs/pull/3695), none. ### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con. None ### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those? None ## Has a call-for-testing period been conducted? If so, what feedback was received? Yes; only positive feedback was received. ## Implementation quality ### Summarize the major parts of the implementation and provide links into the code (or to PRs) Implemented in [#131034](https://github.com/rust-lang/rust/pull/131034). ### Summarize existing test coverage of this feature - [Basic usage, including `#[cfg()]`, `cfg!()` and `#[cfg_attr()]`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/true-false.rs) - [`--cfg=true/false` on the command line being accessible via `r#true/r#false`](https://github.com/rust-lang/rust/blob/6d71251cf9e40326461f90f8ff9a7024706aea87/tests/ui/cfg/raw-true-false.rs) - [Interaction with the unstable `#[doc(cfg(..))]` feature](https://github.com/rust-lang/rust/tree/6d71251/tests/rustdoc-ui/cfg-boolean-literal.rs) - [Denying `--check-cfg=cfg(true/false)`](https://github.com/rust-lang/rust/tree/6d71251/tests/ui/check-cfg/invalid-arguments.rs) - Ensuring `--cfg false` on the command line doesn't change the meaning of `cfg(false)`: `tests/ui/cfg/cmdline-false.rs` - Ensuring both `cfg(true)` and `cfg(false)` on the same item result in it being disabled: `tests/ui/cfg/both-true-false.rs` ### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking? The above mentioned issue; it should not block as it interacts with another unstable feature. ### What FIXMEs are still in the code for that feature and why is it ok to leave them there? None ### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization - `@clubby789` (RFC) - `@Urgau` (Implementation in rustc) ### Which tools need to be adjusted to support this feature. Has this work been done? `rustdoc`'s unstable`#[doc(cfg(..)]` has been updated to respect it. `cargo` has been updated with a forward compatibility lint to enable supporting it in cargo once stabilized. ## Type system and execution rules ### What updates are needed to the reference/specification? (link to PRs when they exist) A few lines to be added to the reference for configuration predicates, specified in the RFC.
2025-04-16Remove old diagnostic notes for type ascription syntaxZalathar-9/+0
Type ascription syntax was removed in 2023.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-09 00:25:23 +0000