about summary refs log tree commit diff
path: root/tests/ui/borrowck
AgeCommit message (Collapse)AuthorLines
2023-12-07recurse into refs when comparing tys for diagnosticsjyn-4/+4
2023-12-04Provide more suggestions for cloning immutable bindingsEsteban Küber-9/+95
When encountering multiple mutable borrows, suggest cloning and adding derive annotations as needed. ``` error[E0596]: cannot borrow `sm.x` as mutable, as it is behind a `&` reference --> $DIR/accidentally-cloning-ref-borrow-error.rs:32:9 | LL | foo(&mut sm.x); | ^^^^^^^^^ `sm` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: `Str` doesn't implement `Clone`, so this call clones the reference `&Str` --> $DIR/accidentally-cloning-ref-borrow-error.rs:31:21 | LL | let mut sm = sr.clone(); | ^^^^^^^ help: consider annotating `Str` with `#[derive(Clone)]` | LL + #[derive(Clone)] LL | struct Str { | help: consider specifying this binding's type | LL | let mut sm: &mut Str = sr.clone(); | ++++++++++ ``` ``` error[E0596]: cannot borrow `*inner` as mutable, as it is behind a `&` reference --> $DIR/issue-91206.rs:14:5 | LL | inner.clear(); | ^^^^^ `inner` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: you can `clone` the `Vec<usize>` value and consume it, but this might not be your desired behavior --> $DIR/issue-91206.rs:11:17 | LL | let inner = client.get_inner_ref(); | ^^^^^^^^^^^^^^^^^^^^^^ help: consider specifying this binding's type | LL | let inner: &mut Vec<usize> = client.get_inner_ref(); | +++++++++++++++++ ```
2023-12-04Mark more tests as `run-rustfix`Esteban Küber-1/+9
2023-12-04Suggest cloning and point out obligation errors on move errorEsteban Küber-17/+91
When encountering a move error, look for implementations of `Clone` for the moved type. If there is one, check if all its obligations are met. If they are, we suggest cloning without caveats. If they aren't, we suggest cloning while mentioning the unmet obligations, potentially suggesting `#[derive(Clone)]` when appropriate. ``` error[E0507]: cannot move out of a shared reference --> $DIR/suggest-clone-when-some-obligation-is-unmet.rs:20:28 | LL | let mut copy: Vec<U> = map.clone().into_values().collect(); | ^^^^^^^^^^^ ------------- value moved due to this method call | | | move occurs because value has type `HashMap<T, U, Hash128_1>`, which does not implement the `Copy` trait | note: `HashMap::<K, V, S>::into_values` takes ownership of the receiver `self`, which moves value --> $SRC_DIR/std/src/collections/hash/map.rs:LL:COL help: you could `clone` the value and consume it, if the `Hash128_1: Clone` trait bound could be satisfied | LL | let mut copy: Vec<U> = <HashMap<T, U, Hash128_1> as Clone>::clone(&map.clone()).into_values().collect(); | ++++++++++++++++++++++++++++++++++++++++++++ + help: consider annotating `Hash128_1` with `#[derive(Clone)]` | LL + #[derive(Clone)] LL | pub struct Hash128_1; | ``` Fix #109429.
2023-12-04Tweak `.clone()` suggestion to work in more casesEsteban Küber-8/+8
When going through auto-deref, the `<T as Clone>` impl sometimes needs to be specified for rustc to actually clone the value and not the reference. ``` error[E0507]: cannot move out of dereference of `S` --> $DIR/needs-clone-through-deref.rs:15:18 | LL | for _ in self.clone().into_iter() {} | ^^^^^^^^^^^^ ----------- value moved due to this method call | | | move occurs because value has type `Vec<usize>`, which does not implement the `Copy` trait | note: `into_iter` takes ownership of the receiver `self`, which moves value --> $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 | for _ in <Vec<usize> as Clone>::clone(&self.clone()).into_iter() {} | ++++++++++++++++++++++++++++++ + ``` CC #109429.
2023-11-28Fix a typo in a `format_args!` noteJosh Stone-2/+2
2023-11-24Show number in error message even for one errorNilstrieb-169/+169
Co-authored-by: Adrian <adrian.iosdev@gmail.com>
2023-11-21Rollup merge of #118035 - ouz-a:november_ice2, r=compiler-errorsNilstrieb-0/+58
Fix early param lifetimes in generic_const_exprs In cases like below, we never actually be able to capture region name for two reasons, first `'static` becomes anonymous lifetime and second we never capture region if it doesn't have a name so this results in ICE. ``` struct DataWrapper<'static> { data: &'a [u8; Self::SIZE], } impl DataWrapper<'a> { ``` Fixes https://github.com/rust-lang/rust/issues/118021
2023-11-20Fix early param lifetimes in generic_const_exprsouz-a-0/+58
2023-11-12Note about object lifetime defaults in does not live long enough errorNilstrieb-0/+4
This is a aspect of Rust that frequently trips up people who are not aware of it yet. This diagnostic attempts to explain what's happening and why the lifetime constraint, that was never mentioned in the source, arose.
2023-11-02Don't check for alias bounds in liveness when aliases have escaping bound varsMichael Goulet-0/+55
2023-10-29Auto merge of #116733 - compiler-errors:alias-liveness-but-this-time-sound, ↵bors-0/+195
r=aliemjay Consider alias bounds when computing liveness in NLL (but this time sound hopefully) This is a revival of #116040, except removing the changes to opaque lifetime captures check to make sure that we're not triggering any unsoundness due to the lack of general existential regions and the currently-existing `ReErased` hack we use instead. r? `@aliemjay` -- I appreciate you pointing out the unsoundenss in the previous iteration of this PR, and I'd like to hear that you're happy with this iteration of this PR before this goes back into FCP :> Fixes #116794 as well --- (mostly copied from #116040 and reworked slightly) # Background Right now, liveness analysis in NLL is a bit simplistic. It simply walks through all of the regions of a type and marks them as being live at points. This is problematic in the case of aliases, since it requires that we mark **all** of the regions in their args[^1] as live, leading to bugs like #42940. In reality, we may be able to deduce that fewer regions are allowed to be present in the projected type (or "hidden type" for opaques) via item bounds or where clauses, and therefore ideally, we should be able to soundly require fewer regions to be live in the alias. For example: ```rust trait Captures<'a> {} impl<T> Captures<'_> for T {} fn capture<'o>(_: &'o mut ()) -> impl Sized + Captures<'o> + 'static {} fn test_two_mut(mut x: ()) { let _f1 = capture(&mut x); let _f2 = capture(&mut x); //~^ ERROR cannot borrow `x` as mutable more than once at a time } ``` In the example above, we should be able to deduce from the `'static` bound on `capture`'s opaque that even though `'o` is a captured region, it *can never* show up in the opaque's hidden type, and can soundly be ignored for liveness purposes. # The Fix We apply a simple version of RFC 1214's `OutlivesProjectionEnv` and `OutlivesProjectionTraitDef` rules to NLL's `make_all_regions_live` computation. Specifically, when we encounter an alias type, we: 1. Look for a unique outlives bound in the param-env or item bounds for that alias. If there is more than one unique region, bail, unless any of the outlives bound's regions is `'static`, and in that case, prefer `'static`. If we find such a unique region, we can mark that outlives region as live and skip walking through the args of the opaque. 2. Otherwise, walk through the alias's args recursively, as we do today. ## Limitation: Multiple choices This approach has some limitations. Firstly, since liveness doesn't use the same type-test logic as outlives bounds do, we can't really try several options when we're faced with a choice. If we encounter two unique outlives regions in the param-env or bounds, we simply fall back to walking the opaque via its args. I expect this to be mostly mitigated by the special treatment of `'static`, and can be fixed in a forwards-compatible by a more sophisticated analysis in the future. ## Limitation: Opaque hidden types Secondly, we do not employ any of these rules when considering whether the regions captured by a hidden type are valid. That causes this code (cc #42940) to fail: ```rust trait Captures<'a> {} impl<T> Captures<'_> for T {} fn a() -> impl Sized + 'static { b(&vec![]) } fn b<'o>(_: &'o Vec<i32>) -> impl Sized + Captures<'o> + 'static {} ``` We need to have existential regions to avoid [unsoundness](https://github.com/rust-lang/rust/pull/116040#issuecomment-1751628189) when an opaque captures a region which is not represented in its own substs but which outlives a region that does. ## Read more Context: https://github.com/rust-lang/rust/pull/115822#issuecomment-1731153952 (for the liveness case) More context: https://github.com/rust-lang/rust/issues/42940#issuecomment-455198309 (for the opaque capture case, which this does not fix) [^1]: except for bivariant region args in opaques, which will become less relevant when we move onto edition 2024 capture semantics for opaques.
2023-10-24Use `PlaceMention` for match scrutinees.Camille GILLOT-353/+138
2023-10-20s/generator/coroutine/Oli Scherer-5/+5
2023-10-17Flesh out tests moreMichael Goulet-7/+128
2023-10-14Consider static speciallyMichael Goulet-0/+28
2023-10-14Consider param-env candidates, tooMichael Goulet-0/+20
2023-10-14Consider alias bounds when considering lliveness for alias types in NLLMichael Goulet-0/+26
2023-10-05Add a note to duplicate diagnosticsAlex Macleod-0/+1
2023-09-23Bless tests.Camille GILLOT-76/+1
2023-09-22Auto merge of #115696 - RalfJung:closure-ty-print, r=oli-obkbors-5/+5
adjust how closure/generator types are printed I saw `&[closure@$DIR/issue-20862.rs:2:5]` and I thought it is a slice type, because that's usually what `&[_]` is... it took me a while to realize that this is just a confusing printer and actually there's no slice. Let's use something that cannot be mistaken for a regular type.
2023-09-21adjust how closure/generator types and rvalues are printedRalf Jung-5/+5
2023-09-19rustc_hir_analysis: add a helper to check function the signature mismatchesEduardo Sánchez Muñoz-5/+6
This function is now used to check `#[panic_handler]`, `start` lang item, `main`, `#[start]` and intrinsic functions. The diagnosis produced are now closer to the ones produced by trait/impl method signature mismatch.
2023-09-14don't point at const usage site for resolution-time errorsRalf Jung-3/+3
also share the code that emits the actual error
2023-09-11Auto merge of #115308 - chenyukang:yukang-fix-62387-iter-mut, r=davidtwcobors-0/+233
suggest iter_mut() where trying to modify elements from .iter() Fixes https://github.com/rust-lang/rust/issues/115259 Fixes https://github.com/rust-lang/rust/issues/62387
2023-09-06Rollup merge of #114511 - chenyukang:yukang-fix-114374-fmt-args, r=b-naberMatthias Krüger-0/+49
Remove the unhelpful let binding diag comes from FormatArguments Fixes #114374
2023-09-07suggest iter_mut() where trying to modify elements from .iter()yukang-0/+233
2023-08-23Suggest mutable borrow on read only for-loop that should be mutableEsteban Küber-0/+76
``` error[E0596]: cannot borrow `*test` as mutable, as it is behind a `&` reference --> $DIR/suggest-mut-iterator.rs:22:9 | LL | for test in &tests { | ------ this iterator yields `&` references LL | test.add(2); | ^^^^ `test` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: use a mutable iterator instead | LL | for test in &mut tests { | +++ ``` Address #114311.
2023-08-23Remove the unhelpful let binding diag comes from FormatArgumentsyukang-0/+49
2023-08-04Improve spans for indexing expressionsNilstrieb-24/+24
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location. This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
2023-07-28Account for macros when suggesting a new let bindingEsteban Küber-1/+5
2023-07-14fix the issue of shorthand in suggest_cloningyukang-3/+4
2023-07-14use maybe_body_owned_by for closureyukang-0/+84
2023-07-10Don't use method span on clone suggestionMichael Goulet-2/+45
2023-07-10Do not set up wrong span for adjustmentsMichael Goulet-198/+161
2023-06-06Rollup merge of #112019 - jieyouxu:issue-111554, r=compiler-errorsMatthias Krüger-0/+57
Don't suggest changing `&self` and `&mut self` in function signature to be mutable when taking `&mut self` in closure Current suggestion for when taking a mutable reference to `self` in a closure (as an upvar) will produce a machine-applicable suggestion to change the `self` in the function signature to `mut self`, but does not account for the specialness of implicit self in that it can already have `&` and `&mut` (see #111554). This causes the function signature to become `test(&mut mut self)` which does not seem desirable. ``` error[E0596]: cannot borrow `self` as mutable, as it is not declared as mutable --> src/sound_player.rs:870:11 | 869 | pub fn test(&mut self) { | ---- help: consider changing this to be mutable: `mut self` 870 | || test2(&mut self); | ^^^^^^^^^ cannot borrow as mutable ``` This PR suppresses the "changing this to be mutable" suggestion if the implicit self is either `ImplicitSelfKind::ImmRef` or `ImplicitSelfKind::MutRef`. Fixes #111554.
2023-05-29Don't suggest changing {ImmRef,MutRef} implicit self to be mutable许杰友 Jieyou Xu (Joe)-0/+57
2023-05-28Auto merge of #111813 - scottmcm:pretty-mir, r=cjgillotbors-1/+1
MIR: opt-in normalization of `BasicBlock` and `Local` numbering This doesn't matter at all for actual codegen, but after spending some time reading pre-codegen MIR, I was wishing I didn't have to jump around so much in reading post-inlining code. So this add two passes that are off by default for every mir level, but can be enabled (`-Zmir-enable-passes=+ReorderBasicBlocks,+ReorderLocals`) for humans.
2023-05-25Remove DesugaringKind::Replace.Camille GILLOT-16/+11
2023-05-21Tweak the post-order for multi-successor blocksScott McMurray-1/+1
2023-05-21Rename `drop_ref` lint to `dropping_references`Urgau-1/+1
2023-05-21Rename `drop_copy` lint to `dropping_copy_types`Urgau-2/+2
2023-05-14Erase ReError properlyMichael Goulet-0/+47
2023-05-10Adjust tests for new drop and forget lintsUrgau-0/+4
2023-05-09Rollup merge of #110583 - Ezrashaw:tweak-make-mut-spans, r=estebankDylan DPC-26/+26
tweak "make mut" spans when assigning to locals Work towards fixing #106857 This PR just cleans up a lot of spans which is helpful before properly fixing the issues. Best reviewed commit-by-commit. r? `@estebank`
2023-05-08Rollup merge of #110827 - compiler-errors:issue-110761-followup, r=cjgillotDylan DPC-0/+54
Fix lifetime suggestion for type aliases with objects in them Fixes an issue identified in https://github.com/rust-lang/rust/issues/110761#issuecomment-1520678479 This suggestion, like many other borrowck suggestions, are very fragile and there are other ways to trigger strange behavior even after this PR, so this is just a small improvement and not a total rework :skull:
2023-05-05tweak "make mut" spans (No. 3)Ezra Shaw-19/+19
2023-05-05tweak "make mut" spans when assigning to localsEzra Shaw-7/+7
2023-04-30Leave promoteds untainted by errors when borrowck failsTomasz Miąsko-0/+26
Previously, when borrowck failed it would taint all promoteds within the MIR body. An attempt to evaluated the promoteds would subsequently fail with spurious "note: erroneous constant used". For example: ```console ... note: erroneous constant used --> tests/ui/borrowck/tainted-promoteds.rs:7:9 | 7 | a = &0 * &1 * &2 * &3; | ^^ note: erroneous constant used --> tests/ui/borrowck/tainted-promoteds.rs:7:14 | 7 | a = &0 * &1 * &2 * &3; | ^^ note: erroneous constant used --> tests/ui/borrowck/tainted-promoteds.rs:7:19 | 7 | a = &0 * &1 * &2 * &3; | ^^ note: erroneous constant used --> tests/ui/borrowck/tainted-promoteds.rs:7:24 | 7 | a = &0 * &1 * &2 * &3; | ^^ ``` Borrowck failure doesn't indicate that there is anything wrong with promoteds. Leave them untainted.
2023-04-25Fix lifetime suggestion for type aliases with objects in themMichael Goulet-0/+54
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 19:53:50 +0000