std_wildcard_imports to lint against use std::mod::*

[tgross35]

What it does

This is a version of wildcard_imports that affects only imports from the standard crates std, core, proc_macro, alloc, and test.

Advantage

wildcard_imports is in pedantic, which seems reasonable for most crates. However, using glob imports from the standard library means that upgrading Rust version can break the build. Recent examples:

• regression: error[E0658]: use of unstable library feature proc_macro_totokens rust#134707
• regression: error[E0659]: Entry is ambiguous rust#134714
• regression: Sign is ambiguous rust#135672

I am proposing std_wildcard_imports as a separate lint from wildcard_imports so it can get enabled by default, likely in clippy::style (or possibly uplifted rust-lang/rust#135672 (comment))

Drawbacks

Confusion between wildcard_imports and std_wildcard_imports, noise on existing code, sometimes use proc_macro::* or similar is fine for testing.

Example

Lint on glob imports:

use std::mem::*; // error
use core::sync::*; // error
use proc_macro::*; // error

However, using glob imports from prelude modules should not raise this warning:

use std::io::prelude::*; // ok
use std::prelude::rust_2021:* // unlikely, but still ok

Non-std crates don't raise this lint

use regex::*; // ok

[tgross35]

Quick usage search https://github.com/search?q=lang%3Arust+%2Fuse+%28std%7Ccore%7Cproc_macro%29.*%3A%3A%5C*%2F&type=code. Most of those are io::prelude, but there are at least a handful of results on the first few pages that would be linted.

[jieyouxu]

There's a caveat that the prelude modules like std::io::prelude::* can still participate in breakage, in that a user may glob import another external crate in addition to glob imports of one of these std preludes, then if that external crate adds something that collides with the (practically frozen) std preludes, you can still end up with glob-vs-glob ambiguous. Less likely of course, agreed with not linting on std preludes.