Add check for += typo in let chains

[Kivooeo]

Fixes #147664

it does affect only cases where variable exist in scope, because if the variable is not exist in scope, the suggestion will not make any sense

I wanted to add suggestion for case where variable does not in scope to fix y += 1 to let y = 1 but I guess it's too much (not too much work, but too much wild predict of what user wants)? if it's good addition in your opinion I can add this in follow up

in other things I guess impl is pretty much self-explanatory, if you see there is some possibilities to improve code or/and some edge-cases that I could overlooked feel free to tell about it

ah, also about why I think this change is good and why I originally took it, so it seems to me that this is possible to make this typo (I explained this in comment a little), like, both + and = is the same button (in most of layouts) and for this reasons I didn't added something like -= it seems more harder to make this typo

r? diagnostics

[Kivooeo]

(info for assigned reviewer or whoever wants pick this up for review, if you found that this is in good state as it, and there is nothing crucial that needed to be added or improved, and you want to rollup this, please, before doing so run bors try on aarch64-msvc-1, i have some kind of paranoia after this #147421 (comment), thanks)

[aklaiber]

A suggestion to improve readability: Add a layer of abstraction to this 535-line check_overloaded_binop method.

#64297

[Kivooeo]

@aklaiber I'm quite unsure, but in my opinion this is a little outside the scope of the current PR

[davidtwco]

It would be nice if some of this logic could be extracted into a function (in a diagnostics module) to keep this function a bit more readable.

[Kivooeo]

Hm, I can extract this if let guard check into a function so it will be looks like this (this if true else false pattern looks bad, but I'm not sure I can use let chains without it)

    fn check(assign_op: Spanned<AssignOpKind>, lhs_expr: hir::Expr<'_>) -> bool {
        if assign_op.node == hir::AssignOpKind::AddAssign
            && let hir::ExprKind::Binary(bin_op, left, right) = &lhs_expr.kind
            && bin_op.node == hir::BinOpKind::And
            && Self::contains_let_in_chain(left)
            && let hir::ExprKind::Path(hir::QPath::Resolved(_, path)) = &right.kind
            && matches!(path.res, hir::def::Res::Local(_))
        {
            true
        } else {
            false
        }
    }


Op::AssignOp(assign_op) if check(assign_op, lhs_expr) => { ... }

Would it make it more readable, or have you meant something different? I guess I'm not fully got the part about diagnostics module

[davidtwco]

It could be something like

if let Err(e) = errors::maybe_emit_plus_equals_diagnostic(..) {
    return (e, None);
}
let (mut err, output_def_id) = match op {
    // ....
}

it just means that we've got less of this kind of handling-a-very-specific-case logic mixed in with everything else

[Kivooeo]

Well, I tried, it's literally was first time me interacting with errors.rs in that way 😅

Usually I add new diagnostic struct in that file, but not a function to check

Hope I got you right here, also, I wasn't be able, to do exact same logic as you showed above, just because this early return from this if let branch will not match the type that function returns, so I merged this into match branch (you'll see my approach)

[Kivooeo]

By the way, do we prefer to use import or this explicit path are also fine?