`std_instead_of_core` creates an invalid fix on stacked imports

[MarcusGrass]

Summary

Found while fixing this one #12406.

It has existed probably since this lint was created, but became problematic once the clippy-fix was added.

The problem is that check_path will get each path separately, i.e. for:

use std::{fmt::Result, io::Write};

There will be two passes, and to the code, the paths will look like:

use std::fmt::Result;
// And separately
use std::io::Write;

But, the code will deduce that they are from the same import because the std-span is the same on those two passes, and it keeps the last span saved.

// Not problematic, will skip everything after the first io::Write which can't be taken from core
use std::{io::Write, fmt::Result};
// Is problematic, since it will recognize that fmt::Result can be taken from core
use std::{fmt::Result, io::Write};

There's some nuance here, in the case that the path is a part of a stacked import, each path in that import needs to be known to ensure that the fix will be valid, and at least with check_path that's hard to know without looking ahead.

Reproducer

I tried this code:

use std::{fmt::Result, io::Write};

I expected to see this happen:
Warn that std::fmt::Result can be imported from core and either:

1. Don't fix, since core::io::Write does not exist.
2. Fix by splitting up the import.

Instead, this happened:
std is replaced by core which doesn't compile.

Version

rustc 1.78.0-nightly (7d3702e47 2024-03-06)
binary: rustc
commit-hash: 7d3702e472b99be0f5de6608dd87af1df8f99428
commit-date: 2024-03-06
host: x86_64-unknown-linux-gnu
release: 1.78.0-nightly
LLVM version: 18.1.0

Additional Labels

No response