Tracking Issue: Bugs introduced by Rustup #3905

[flip1995]

This is a tracking issue for the bugs introduced by #3905. This is only a summary, more debugging attempts can be found in the PR:

• FP identity_conversion on read_dir()?: Fixed Make most macro checks also check for desugarings #4082

Summary: This FP happens, because the code is expanded to HIR code, which includes a line containing From::from(err). This gets linted, but shouldn't. Previously it got expanded to the same HIR code, but didn't get linted.

Minimal example:

use std::path::Path;
use std::fs;

fn main() {
    let path = Path::new(".");
    for _ in fs::read_dir(path)? {}
}

• Missing suggestion on explicit_iter_loop

Summary: Even though span_lint_and_sugg is used, no suggestion is displayed, but also no error or ICE. This problem came up once before on something completely unrelated: #3582 (comment). (This could be a problem in rustc, in the suggestion emitting code.)

Minimal example:

#[warn(clippy::explicit_iter_loop)]
fn main() {
    let v = vec![1];
    for _ in v.iter() { }
}

• FN into_iter_on_array when into_iter() is called in the for-loop head

Summary: The problem is, that the into_iter MethodCall in the expanded HIR code is seen as macro expanded code, so that is_macro returns true for the span of the MethodCall expression. The HIR expanded code didn't change recently, so something must have changed in rustc, determining if an expression comes from a macro expansion.

Minimal example:

fn main() {
    for _ in [1, 2, 3].into_iter() {}
}

[phansch]

This is not an issue anymore, since the changes have been rolled back, or?

[Manishearth]

Only the libtest changes were rolled back

[flip1995]

Regression tests are in #3936

[flip1995]

Citing @estebank from #3944 (comment): (identity_conversion bug)

@flip1995 I believe we can get around that by touching https://github.com/rust-lang/rust/blob/9217fe0e2f04d61dd29c9aaebee2c993705e1d26/src/librustc/hir/lowering.rs#L4667-L4774

We can mark any of the mentioned spans with CompilerDesugaringKind::QuestionMark as a reason, we just need to identify which span it should be (or mark all of them, which should be fine, depending on how that mark is used elsewhere).

[ReinierMaas]

I would have found this problem quicker if it was mentioned in the Lints: Known problems

[flip1995]

identity_conversion is fixed in the latest version. a5bcaf5

[flip1995]

Everything listed here got fixed. Verified in #3936