Description
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_conversiononread_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_arraywheninto_iter()is called in thefor-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() {}
}