Code change:
<ins> error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:4:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     dbg!(a); |     ------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(&a); |          + error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:10:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     dbg!(1, 2, a, 1, 2); |     ------------------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(1, 2, &a, 1, 2); |                + error[E0382]: use of moved value: `b` --> $DIR/dbg-issue-120327.rs:16:12 | LL |     let b: String = "".to_string(); |         - move occurs because `b` has type `String`, which does not implement the `Copy` trait LL |     dbg!(a, b); |     ---------- value moved here LL |     return b; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(a, &b); |             + error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:22:12 | LL | fn x(a: String) -> String { |      - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let b: String = "".to_string(); LL |     dbg!(a, b); |     ---------- value moved here LL |     return a; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     dbg!(&a, b); |          + error[E0382]: use of moved value: `b` --> $DIR/dbg-issue-120327.rs:46:12 | LL |             tmp => { |             --- value moved here ... LL |     let b: String = "".to_string(); |         - move occurs because `b` has type `String`, which does not implement the `Copy` trait LL |     my_dbg!(b, 1); LL |     return b; |            ^ value used here after move | help: consider borrowing instead of transferring ownership | LL |     my_dbg!(&b, 1); |             + help: borrow this binding in the pattern to avoid moving the value | LL |             ref tmp => { |             +++ error[E0382]: use of moved value: `a` --> $DIR/dbg-issue-120327.rs:57:12 | LL |     let a = String::new(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let _b = match a { LL |         tmp => { |         --- value moved here ... LL |     return a; |            ^ value used here after move | help: borrow this binding in the pattern to avoid moving the value | LL |         ref tmp => { |         +++ error[E0382]: borrow of moved value: `a` --> $DIR/dbg-issue-120327.rs:65:14 | LL |     let a: String = "".to_string(); |         - move occurs because `a` has type `String`, which does not implement the `Copy` trait LL |     let _res = get_expr(dbg!(a)); |                         ------- value moved here LL |     let _l = a.len(); |              ^ value borrowed here after move | help: consider borrowing instead of transferring ownership | LL |     let _res = get_expr(dbg!(&a)); |                              + error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0382`. </ins>

Related discussion:
text: No response No response No response
I thought the intent with was to use it in a passthrough style, so you can insert it into existing expressions ie. becomes . In which case, maybe the lint should be for not using the value resulting from evaluating .
Not sure about the majority of users but for me is a convenience over . I use it without using the return value almost all of the time.
Probably a common thing to do, sure, but if we're talking about adding a lint, why not nudge the user in the direction of the intended and documented usage? You could at least do both: "insert into an existing expression or pass it a borrow" etc.
The fix in will only report a hint when there is already a happened. For example this code: before this fix the error is: with the fix, since there is already a error, the lint will try to find out the original macro, and suggest a borrow: The suggestion is not 100% right, since if we change it to , we need one more extra fix now(the return type is not expecting a reference), but there is a different issue, at least we have already moved one step on. If the original code is: Then suggest a borrow is a great and correct hint.
Similar in the scenario of function argument: original error is: new errors from the fix:
Would not also be a good hint? The suggestion wouldn't compile anyway right? Because would need to change to take ? Without involved, the compiler does indeed suggest that: Once that's addressed (whichever way it's done), once again becomes transparent, and eg. or works. does not, however, and I see why a "consider borrowing" hint would be good there. However, if you make the change first and leave as-is, the resulting error does not include the suggestion to change , which is unhelpful. (I agree that the message is even less helpful though, I'm not disputing that.)
Yes, it's a good hint, but from the implementation view of a hint, it's much harder to analyze the following code from the error point and then construct a new expression. Even it seems an easy thing for humans. You are right, the suggestion is not 100% right, we may need an extra follow-up fix after applying the hint, which is also a common thing in rustc diagnostics.