about summary refs log tree commit diff
path: root/compiler/rustc_borrowck/src/diagnostics
AgeCommit message (Collapse)AuthorLines
2025-08-01Auto merge of #144446 - nnethercote:opt-region-constraints, r=lcnrbors-20/+19
Optimize region constraints r? `@lcnr`
2025-07-31Overhaul `Constraint`.Nicholas Nethercote-20/+19
This commit changes it to store a `Region` instead of a `RegionVid` for the `Var` cases: - We avoid having to call `Region::new_var` to re-create `Region`s from `RegionVid`s in a few places, avoiding the interning process, giving a small perf win. (At the cost of the type allowing some invalid combinations of values.) - All the cases now store two `Region`s, so the commit also separates the `ConstraintKind` (a new type) from the `sub` and `sup` arguments in `Constraint`.
2025-07-31Remove `ParamEnvAnd::into_parts`.Nicholas Nethercote-2/+2
The fields are public, so this doesn't need a method, normal deconstruction and/or field access is good enough.
2025-07-29Create two methods to fix `find_oldest_ancestor_in_same_ctxt`xizheyin-1/+1
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-07-28Rename impl_of_method -> impl_of_assocCameron Steffen-3/+3
2025-07-28Rename trait_of_item -> trait_of_assocCameron Steffen-2/+2
2025-07-28Auto merge of #144469 - Kivooeo:chains-cleanup, r=SparrowLiibors-247/+236
Some `let chains` clean-up Not sure if this kind of clean-up is welcoming because of size, but I decided to try out one r? compiler
2025-07-28use let chains in ast, borrowck, codegen, const_evalKivooeo-247/+236
2025-07-25Mention type that could be `Clone` but isn't in more casesEsteban Küber-0/+52
When encountering a moved value of a type that isn't `Clone` because of unmet obligations, but where all the unmet predicates reference crate-local types, mention them and suggest cloning, as we do in other cases already: ``` error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure --> f111.rs:14:25 | 13 | fn do_stuff(foo: Option<Foo>) { | --- captured outer variable 14 | require_fn_trait(|| async { | -- ^^^^^ `foo` is moved here | | | captured by this `Fn` closure 15 | if foo.map_or(false, |f| f.foo()) { | --- | | | variable moved due to use in coroutine | move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait | note: if `Foo` implemented `Clone`, you could clone the value --> f111.rs:4:1 | 4 | struct Foo; | ^^^^^^^^^^ consider implementing `Clone` for this type ... 15 | if foo.map_or(false, |f| f.foo()) { | --- you could clone this value ```
2025-07-25Rollup merge of #144200 - estebank:dont-point-at-closure, r=lcnrMatthias Krüger-51/+83
Tweak output for non-`Clone` values moved into closures When we encounter a non-`Clone` value being moved into a closure, try to find the corresponding type of the binding being moved, if it is a `let`-binding or a function parameter. If any of those cases, we point at them with the note explaining that the type is not `Copy`, instead of giving that label to the place where it is captured. When it is a `let`-binding with no explicit type, we point at the initializer (if it fits in a single line). ``` error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure --> f111.rs:14:25 | 13 | fn do_stuff(foo: Option<Foo>) { | --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait | | | captured outer variable 14 | require_fn_trait(|| async { | -- ^^^^^ `foo` is moved here | | | captured by this `Fn` closure 15 | if foo.map_or(false, |f| f.foo()) { | --- variable moved due to use in coroutine ``` instead of ``` error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure --> f111.rs:14:25 | 13 | fn do_stuff(foo: Option<Foo>) { | --- captured outer variable 14 | require_fn_trait(|| async { | -- ^^^^^ `foo` is moved here | | | captured by this `Fn` closure 15 | if foo.map_or(false, |f| f.foo()) { | --- | | | variable moved due to use in coroutine | move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait ```
2025-07-23Point at the type that doesn't impl `Clone` in more cases beyond closuresEsteban Küber-10/+5
2025-07-21Reduce comment verbosityEsteban Küber-33/+5
2025-07-21Tweak spans when encountering multiline initializer in move errorEsteban Küber-2/+9
``` error[E0507]: cannot move out of `f`, a captured variable in an `FnMut` closure --> $DIR/borrowck-call-is-borrow-issue-12224.rs:57:13 | LL | let mut f = move |g: Box<dyn FnMut(isize)>, b: isize| { | ----- captured outer variable ... LL | f(Box::new(|a| { | --- captured by this `FnMut` closure LL | LL | foo(f); | ^ move occurs because `f` has type `{closure@$DIR/borrowck-call-is-borrow-issue-12224.rs:52:17: 52:58}`, which does not implement the `Copy` trait ``` instead of ``` error[E0507]: cannot move out of `f`, a captured variable in an `FnMut` closure --> $DIR/borrowck-call-is-borrow-issue-12224.rs:57:13 | LL | let mut f = move |g: Box<dyn FnMut(isize)>, b: isize| { | _________-----___- | | | | | captured outer variable LL | | let _ = s.len(); LL | | }; | |_____- move occurs because `f` has type `{closure@$DIR/borrowck-call-is-borrow-issue-12224.rs:52:17: 52:58}`, which does not implement the `Copy` trait LL | f(Box::new(|a| { | --- captured by this `FnMut` closure LL | LL | foo(f); | ^ `f` is moved here ```
2025-07-21Generalize logic pointing at binding moved into closureEsteban Küber-24/+55
Account not only for `fn` parameters when moving non-`Copy` values into closure, but also for let bindings. ``` error[E0507]: cannot move out of `bar`, a captured variable in an `FnMut` closure --> $DIR/borrowck-move-by-capture.rs:9:29 | LL | let bar: Box<_> = Box::new(3); | --- ------ move occurs because `bar` has type `Box<isize>`, which does not implement the `Copy` trait | | | captured outer variable LL | let _g = to_fn_mut(|| { | -- captured by this `FnMut` closure LL | let _h = to_fn_once(move || -> isize { *bar }); | ^^^^^^^^^^^^^^^^ ---- variable moved due to use in closure | | | `bar` is moved here | help: consider cloning the value before moving it into the closure | LL ~ let value = bar.clone(); LL ~ let _h = to_fn_once(move || -> isize { value }); | ``` ``` error[E0507]: cannot move out of `y`, a captured variable in an `Fn` closure --> $DIR/unboxed-closures-move-upvar-from-non-once-ref-closure.rs:12:9 | LL | let y = vec![format!("World")]; | - ---------------------- move occurs because `y` has type `Vec<String>`, which does not implement the `Copy` trait | | | captured outer variable LL | call(|| { | -- captured by this `Fn` closure LL | y.into_iter(); | ^ ----------- `y` moved due to this method call | | | `y` is moved here | note: `into_iter` takes ownership of the receiver `self`, which moves `y` --> $SRC_DIR/core/src/iter/traits/collect.rs:LL:COL help: you can `clone` the value and consume it, but this might not be your desired behavior | LL | <Vec<String> as Clone>::clone(&y).into_iter(); | +++++++++++++++++++++++++++++++ + help: consider cloning the value if the performance cost is acceptable | LL | y.clone().into_iter(); | ++++++++ ```
2025-07-21Tweak borrowck label pointing at `!Copy` value moved into closureEsteban Küber-51/+78
When encountering a non-`Copy` value that is moved into a closure which is coming directly from a fn parameter, point at the parameter's type when mentioning it is not `Copy`. Before: ``` error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure --> f111.rs:14:25 | 13 | fn do_stuff(foo: Option<Foo>) { | --- captured outer variable 14 | require_fn_trait(|| async { | -- ^^^^^ `foo` is moved here | | | captured by this `Fn` closure 15 | if foo.map_or(false, |f| f.foo()) { | --- | | | variable moved due to use in coroutine | move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait ``` After: ``` error[E0507]: cannot move out of `foo`, a captured variable in an `Fn` closure --> f111.rs:14:25 | 13 | fn do_stuff(foo: Option<Foo>) { | --- ----------- move occurs because `foo` has type `Option<Foo>`, which does not implement the `Copy` trait | | | captured outer variable 14 | require_fn_trait(|| async { | -- ^^^^^ `foo` is moved here | | | captured by this `Fn` closure 15 | if foo.map_or(false, |f| f.foo()) { | --- variable moved due to use in coroutine ```
2025-07-21Dont ICE on copy error being suppressed due to overflowMichael Goulet-4/+5
2025-07-13Remove hir::AssocItemKind.Camille GILLOT-31/+15
2025-07-04NitsMichael Goulet-2/+2
2025-07-04Fix elided lifetimes in rustdocMichael Goulet-3/+3
2025-07-04Remove Symbol for Named LateParam/Bound variantsMichael Goulet-9/+8
2025-07-01mir: Mark `Statement` and `BasicBlockData` as `#[non_exhaustive]`dianqk-0/+1
Ensure they are always created using constructors.
2025-06-27Auto merge of #143074 - compiler-errors:rollup-cv64hdh, r=compiler-errorsbors-2/+3
Rollup of 18 pull requests Successful merges: - rust-lang/rust#137843 (make RefCell unstably const) - rust-lang/rust#140942 (const-eval: allow constants to refer to mutable/external memory, but reject such constants as patterns) - rust-lang/rust#142549 (small iter.intersperse.fold() optimization) - rust-lang/rust#142637 (Remove some glob imports from the type system) - rust-lang/rust#142647 ([perf] Compute hard errors without diagnostics in impl_intersection_has_impossible_obligation) - rust-lang/rust#142700 (Remove incorrect comments in `Weak`) - rust-lang/rust#142927 (Add note to `find_const_ty_from_env`) - rust-lang/rust#142967 (Fix RwLock::try_write documentation for WouldBlock condition) - rust-lang/rust#142986 (Port `#[export_name]` to the new attribute parsing infrastructure) - rust-lang/rust#143001 (Rename run always ) - rust-lang/rust#143010 (Update `browser-ui-test` version to `0.20.7`) - rust-lang/rust#143015 (Add `sym::macro_pin` diagnostic item for `core::pin::pin!()`) - rust-lang/rust#143033 (Expand const-stabilized API links in relnotes) - rust-lang/rust#143041 (Remove cache for citool) - rust-lang/rust#143056 (Move an ACE test out of the GCI directory) - rust-lang/rust#143059 (Fix 1.88 relnotes) - rust-lang/rust#143067 (Tracking issue number for `iter_macro`) - rust-lang/rust#143073 (Fix some fixmes that were waiting for let chains) Failed merges: - rust-lang/rust#143020 (codegen_fn_attrs: make comment more precise) r? `@ghost` `@rustbot` modify labels: rollup
2025-06-26Rollup merge of #142637 - compiler-errors:less-globs, r=lcnrMichael Goulet-2/+3
Remove some glob imports from the type system Namely, remove the glob imports for `BoundRegionConversionTime`, `RegionVariableOrigin`, `SubregionOrigin`, `TyOrConstInferVar`, `RegionResolutionError`, `SelectionError`, `ProjectionCandidate`, `ProjectionCandidateSet`, and some more specific scoped globs (like `Inserted` in the impl overlap graph construction. These glob imports are IMO very low value, since they're not used nearly as often as other globs (like `TyKind`).
2025-06-26Rollup merge of #124595 - estebank:issue-104232, r=davidtwcoMatthias Krüger-29/+27
Suggest cloning `Arc` moved into closure ``` 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); | ``` Fix rust-lang/rust#104232.
2025-06-25Rollup merge of #142724 - xizheyin:avoid_overwrite_args, r=oli-obkJana Dönszelmann-1/+7
Add runtime check to avoid overwrite arg in `Diag` ## Origin PR description At first, I set up a `debug_assert` check for the arg method to make sure that `args` in `Diag` aren't easily overwritten, and I added the `remove_arg()` method, so that if you do need to overwrite an arg, then you can explicitly call `remove_arg()` to remove it first, then call `arg()` to overwrite it. For the code before the rust-lang/rust#142015 change, it won't compile because it will report an error ``` arg `instance`already exists. ``` This PR also modifies all diagnostics that fail the check to pass the check. There are two cases of check failure: 1. ~~Between *the parent diagnostic and the subdiagnostic*, or *between the subdiagnostics* have the same field between them. In this case, I renamed the conflicting fields.~~ 2. ~~For subdiagnostics stored in `Vec`, the rendering may iteratively write the same arg over and over again. In this case, I changed the auto-generation with `derive(SubDiagnostic)` to manually implementing `SubDiagnostic` and manually rendered it with `eagerly_translate()`, similar to https://github.com/rust-lang/rust/issues/142031#issuecomment-2984812090, and after rendering it I manually deleted useless arg with the newly added `remove_arg` method.~~ ## Final Decision After trying and discussing, we made a final decision. For `#[derive(Subdiagnostic)]`, This PR made two changes: 1. After the subdiagnostic is rendered, remove all args of this subdiagnostic, which allows for usage like `Vec<Subdiag>`. 2. Store `diag.args` before setting arguments, so that you can restore the contents of the main diagnostic after deleting the arguments after subdiagnostic is rendered, to avoid deleting the main diagnostic's arg when they have the same name args.
2025-06-25Remove some glob imports from the type systemMichael Goulet-2/+3
2025-06-25Add runtime check to avoid overwrite arg easily in diag and store and ↵xizheyin-1/+7
restore snapshot when set subdiag arg Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
2025-06-24Suggest cloning `Arc` moved into closureEsteban Küber-29/+27
``` 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-22Init local_names lazily for borrowck diagnosticsKornel-19/+53
2025-06-22Avoid panic when debug info is missingKornel-3/+7
2025-06-19Remove old format_args diagnostic.Mara Bos-27/+11
2025-06-16Handle same-crate macro for borrowck semicolon suggestionUrgau-4/+1
2025-06-15Rollup merge of #142543 - Urgau:span-borrowck-semicolon, r=fmeaseLeón Orell Valerian Liehr-3/+7
Suggest adding semicolon in user code rather than macro impl details This PR tries to find the right span (by peeling expansion) so that the suggestion for adding a semicolon is suggested in user code rather than in the expanded code (in the example a macro impl). Fixes rust-lang/rust#139049 r? `@fmease`
2025-06-15Suggest adding semicolon in user code rather than macro impl detailsUrgau-3/+7
2025-06-12Rollup merge of #141069 - chenyukang:yukang-fix-137486-suggest-mut, r=davidtwcoMatthias Krüger-1/+13
Suggest mut when possbile for temporary value dropped while borrowed Fixes #137486
2025-06-05Replace some `Option<Span>` with `Span` and use DUMMY_SP instead of NoneOli Scherer-2/+2
2025-06-04Don't refer to 'local binding' in extern macro.Mara Bos-1/+7
The user has no clue what 'local binding' the compiler is talking about, if they don't know the expansion of the macro.
2025-06-02fix bug where borrowck tries to describe a name from a macro in another crateJana Dönszelmann-8/+16
2025-05-27Suggest mut when possbile for temporary value dropped while borrowedyukang-1/+13
2025-05-27Fix some var namesMichael Goulet-3/+3
2025-05-27Rename unpack to kindMichael Goulet-2/+2
2025-05-02remove an unused codepathJana Dönszelmann-6/+1
2025-05-02Test that names of variables in external macros are not shown on a borrow errorJana Dönszelmann-0/+8
2025-04-25Rollup merge of #140257 - amandasystems:housecleaning, r=wesleywiserMatthias Krüger-22/+19
Some drive-by housecleaning in `rustc_borrowck` This commit picks up a few odd ends discovered during the work on #130227. It adds some documentation and renames a few methods with too generic names to describe what they actually do. It also adds some debug output that was helpful during bug hunting and generally cleans up a few things (for my values of "clean"). r? lcnr
2025-04-24Some drive-by housecleaning in `rustc_borrowck`Amanda Stjerna-22/+19
This commit picks up a few odd ends discovered during the work on #130227. It adds some documentation and renames a few methods with too generic names to describe what they actually do. It also adds some debug output that was helpful during bug hunting.
2025-04-22Use `is_lang_item` and `as_lang_item` instead of handrolling their logicOli Scherer-6/+1
2025-04-19Auto merge of #139114 - m-ou-se:super-let-pin, r=davidtwcobors-6/+14
Implement `pin!()` using `super let` Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076 This uses `super let` to implement `pin!()`. This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596. It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field. While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable. It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
2025-04-17Rollup merge of #139770 - nnethercote:rename-LifetimeName, r=BoxyUwUMatthias Krüger-1/+1
Rename `LifetimeName` as `LifetimeKind`. It's a much better name, more consistent with how we name such things. Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this field used to have the type `LifetimeRes` and then the type was changed but the field name remained the same. r? ``@BoxyUwU``
2025-04-16Rename `LifetimeName` as `LifetimeKind`.Nicholas Nethercote-1/+1
It's a much better name, more consistent with how we name such things. Also rename `Lifetime::res` as `Lifetime::kind` to match. I suspect this field used to have the type `LifetimeRes` and then the type was changed but the field name remained the same.
2025-04-15Fix wrong suggestion for async gen block and add regression ui test for #139839Guillaume Gomez-4/+9