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
```
```
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
```
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();
| ++++++++
```
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
```
use `is_multiple_of` and `div_ceil`
In tricky logic, these functions are much more informative than the manual implementations. They also catch subtle bugs:
- the manual `is_multiple_of` often does not handle division by zero
- manual `div_ceil` often does not consider overflow
The transformation is free for `is_multiple_of` if the divisor is compile-time known to be non-zero. For `div_ceil` there is a small cost to considering overflow. Here is some assembly https://godbolt.org/z/5zP8KaE1d.
Remove support for `dyn*` from the compiler
This PR removes support for `dyn*` (https://github.com/rust-lang/rust/issues/102425), which are a currently un-RFC'd experiment that was opened a few years ago to explore a component that we thought was necessary for AFIDT (async fn in dyn trait).
It doesn't seem like we are going to need `dyn*` types -- even in an not-exposed-to-the-user way[^1] -- for us to implement AFIDT. Given that AFIDT was the original motivating purpose of `dyn*` types, I don't really see a compelling reason to have to maintain their implementation in the compiler.
[^1]: Compared to, e.g., generators whih are an unstable building block we use to implement stable syntax like `async {}`.
We've learned quite a lot from `dyn*`, but I think at this point its current behavior leads to more questions than answers. For example, `dyn*` support today remains somewhat fragile; it ICEs in many cases where the current "normal" `dyn Trait` types rely on their unsizedness for their vtable-based implementation to be sound I wouldn't be surprised if it's unsound in other ways, though I didn't play around with it too much. See the examples below.
```rust
#![feature(dyn_star)]
trait Foo {
fn hello(self);
}
impl Foo for usize {
fn hello(self) {
println!("hello, world");
}
}
fn main() {
let x: dyn* Foo = 1usize;
x.hello();
}
```
And:
```rust
#![feature(dyn_star)]
trait Trait {
type Out where Self: Sized;
}
fn main() {
let x: <dyn* Trait as Trait>::Out;
}
```
...and probably many more problems having to do with the intersection of dyn-compatibility and `Self: Sized` bounds that I was too lazy to look into like:
* GATs
* Methods with invalid signatures
* Associated consts
Generally, `dyn*` types also end up getting in the way of working with [normal `dyn` types](https://github.com/rust-lang/rust/issues/102425#issuecomment-1712604409) to an extent that IMO outweighs the benefit of experimentation.
I recognize that there are probably other, more creative usages of `dyn*` that are orthogonal to AFIDT. However, I think any work along those lines should first have to think through some of the more fundamental interactions between `dyn*` and dyn-compatibility before we think about reimplementing them in the type system.
---
I'm planning on removing the `DynKind` enum and the `PointerLike` built-in trait from the compiler after this PR lands.
Closesrust-lang/rust#102425.
cc `@eholk` `@rust-lang/lang` `@rust-lang/types`
Closesrust-lang/rust#116979.
Closesrust-lang/rust#119694.
Closesrust-lang/rust#134591.
Closesrust-lang/rust#104800.
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`).
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);
|
```
Fixrust-lang/rust#104232.
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.
```
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);
|
```
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#133952 (Remove wasm legacy abi)
- rust-lang/rust#134661 (Reduce precedence of expressions that have an outer attr)
- rust-lang/rust#141769 (Move metadata object generation for dylibs to the linker code )
- rust-lang/rust#141937 (Report never type lints in dependencies)
- rust-lang/rust#142347 (Async drop - fix for StorageLive/StorageDead codegen for pinned future)
- rust-lang/rust#142389 (Apply ABI attributes on return types in `rustc_codegen_cranelift`)
- rust-lang/rust#142470 (Add some missing mailmap entries)
- rust-lang/rust#142481 (Add `f16` inline asm support for LoongArch)
- rust-lang/rust#142499 (Remove check run bootstrap)
- rust-lang/rust#142543 (Suggest adding semicolon in user code rather than macro impl details)
r? `@ghost`
`@rustbot` modify labels: rollup
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).
Fixesrust-lang/rust#139049
r? `@fmease`
use `MixedBitSet` for borrows-in-scope dataflow analysis
The `Borrows` dataflow analysis uses a dense bitset, but a bitset supporting _some_ amount of sparseness is better suited for big functions with a big number of loans.
The cutoff between dense and chunked bitset is around 2K loans IIRC, and we could finesse that value if we wanted to, but as-is it happens to a couple of rustc-perf benchmarks (which IIRC are at least partially generated from macros and the likes.). It's a small win on these two, and shouldn't have any impact on the others.
r? `@matthewjasper`
Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixesrust-lang/rust#79409
Some code can have a few thousand loans, and this bitset is better
suited to these somewhat sparse cases.
That includes a couple of rustc-perf benchmarks.
Replace some `Option<Span>` with `Span` and use DUMMY_SP instead of None
Turns out many locations actually have a span available that we could use, so I used it
Move placeholder handling to a proper preprocessing step
This commit breaks out the logic of placheolder rewriting into its own preprocessing step. It's one of the more boring
parts of #130227.
The only functional change from this is that the preprocessing step (where extra `r: 'static` constraints are added) is performed upstream of Polonius legacy, finally affecting Polonius. That is mostly a by-product, though.
This should be reviewable by anyone in the compiler team, so
r? rust-lang/compiler
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>
