Account for desugaring in method call move errors - #160006
Conversation
When encountering a move error caused by a desugared method call, talk about the user-facing feature (`await`/`?`/`for`-loop), instead of only the internal API it got desugared to.
```
error[E0382]: use of moved value: `entry`
--> $DIR/moved-into-question-mark.rs:11:18
|
LL | for entry in fs::read_dir(".")? {
| ----- move occurs because `entry` has type `Result<DirEntry, std::io::Error>`, which does not implement the `Copy` trait
LL |
LL | let file_type = entry?.file_type()?;
| ------ `entry` moved due to usage in the question mark operator
...
LL | dbg!(entry?.file_name());
| ^^^^^ value used here after move
|
note: the question mark operator is expanded into a call to `branch`, which takes ownership of the receiver `self`, which moves `entry`
--> $SRC_DIR/core/src/ops/try_trait.rs:LL:COL
help: you could `clone` the value and consume it, if the following trait bounds could be satisfied: `DirEntry: Clone` and `std::io::Error: Clone`
|
LL | let file_type = entry.clone()?.file_type()?;
| ++++++++
```
|
r? @chenyukang rustbot has assigned @chenyukang. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| LL | dbg!(entry?.file_name()); | ||
| | ^^^^^ value used here after move | ||
| | | ||
| note: the question mark operator is expanded into a call to `branch`, which takes ownership of the receiver `self`, which moves `entry` |
There was a problem hiding this comment.
is it better to use desugarded than expanded, not sure.
There was a problem hiding this comment.
Changed, as well as a few other tweaks in the second commit. I think that using the full path to the item makes more sense in this case (it is unlikely to be too long, and the clarity gain is high). LMKWYT.
| | ^^^^ value used here after move | ||
| | | ||
| note: `into_async_iter` takes ownership of the receiver `self`, which moves `iter` | ||
| note: `std::async_iter::IntoAsyncIterator::into_async_iter` takes ownership of the receiver `self`, which moves `iter` |
There was a problem hiding this comment.
it's better we point out the for await here?
maybe:
note: the for await loop is desugared into a call to std::async_iter::IntoAsyncIterator::into_async_iter, which takes ownership of the receiver self and moves iter
|
r=me after a nit. |
|
Some changes occurred to the CTFE machinery Some changes occurred to constck cc @fee1-dead |
When encountering a move error caused by a desugared method call, talk about the user-facing feature (
await/?/for-loop), instead of only the internal API it got desugared to.Fix #89567.