Add new lint: `std_wildcard_imports` by alanbondarun · Pull Request #14868 · rust-lang/rust-clippy

alanbondarun · 2025-05-22T10:50:03Z

changelog: [std_wildcard_imports]: Initial implementation

This fixes #13961.

Please let me know if there any missing test cases and/or changes!

TODO

Fix failed tests from other lints
Add more test cases

rustbot · 2025-05-27T09:43:41Z

rustbot has assigned @llogiq.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

llogiq

There seems to be some duplication with the wildcard_imports lint. It probably makes sense to pull those lint passes together into one pass that implements both lints.

Otherwise I'm dubious about making this a warn-by-default lint, but we can discuss this during the final comment period.

llogiq · 2025-06-02T12:28:39Z

clippy_lints/src/std_wildcard_imports.rs

+    /// Wildcard imports can pollute the namespace. This is especially bad when importing from the
+    /// standard library through wildcards:
+    ///
+    /// ```no_run


This belongs into the Example section.

llogiq · 2025-06-02T12:35:42Z

clippy_lints/src/std_wildcard_imports.rs

+    /// ```
+    #[clippy::version = "1.89.0"]
+    pub STD_WILDCARD_IMPORTS,
+    style,


I'm not sure about the lint group. Yes, namespace pollution is bad. But there are four stdlib namespaces (of which three might be imported from in somewhat normal code), so this could lead to serious churn.

I also don't follow the argument that names imported from std are somehow worse than others. Why? The standard library moves slower than other crates if anything.

(Sorry for late reply) Then how about setting the lint group to pedantic, and denying this lint in Cargo.toml of standard libraries? I think it would solve the issue without editing a bunch of existing codes outside of stdlib.

For some context, the libs team expressed interest in having some form of this builtin at some point rust-lang/rust#135672 (comment). But we likely need a smarter version for that - some discussion at rust-lang/rust#142448.

Based on the discussions in the linked issues, I suggest we close this PR, clearly define what this lint should do, and then implement it accordingly. What do you think of this approach?

Oh I still think this is useful in its current state, just with some updated docs per @jieyouxu's comment. We probably eventually want some version of this as a rustc builtin lint and that will be a bit smarter, but having something in Clippy (regardless of whatever level the maintainers feel comfortable placing it at) definitely helps get us off the ground.

llogiq · 2025-06-02T12:36:45Z

clippy_lints/src/std_wildcard_imports.rs

+                cx,
+                STD_WILDCARD_IMPORTS,
+                span,
+                "usage of wildcard import from `std` crates",


It would be shorter and clearer to replace the "std crates" with the actual crate name.

rustbot · 2025-06-04T05:26:21Z

☔ The latest upstream changes (possibly 84ef7fb) made this pull request unmergeable. Please resolve the merge conflicts.

jieyouxu · 2025-06-18T16:22:43Z

clippy_lints/src/std_wildcard_imports.rs

+    /// Wildcard imports can pollute the namespace. This is especially bad when importing from the
+    /// standard library through wildcards:


Suggestion: as far as I understand it, the motivation of #13961 is mostly not about namespace pollution, but about name resolution breakage (such as introduction of new ambiguities) from people glob-importing std modules, and then std introducing a new item whose name collides with that of an item defined locally. The very bad part about this situation is that even unstable std API editions can introduce name resolution ambiguities.

That is, the strongest motivation for this lint is the name resolution ambiguity related breakages, and not namespace pollution.

alanbondarun · 2025-06-24T12:23:13Z

@rustbot ready

ada4a · 2025-10-11T16:37:44Z

clippy_lints/src/wildcard_imports.rs

    segments.iter().any(|seg| allowed_segments.contains(seg.ident.as_str()))
 }
+
+// Returns the entire span for a given glob import statement, including the `*` symbol.


Suggested change

// Returns the entire span for a given glob import statement, including the `*` symbol.

/// Returns the entire span for a given glob import statement, including the `*` symbol.

ada4a · 2025-10-11T16:37:55Z

clippy_lints/src/wildcard_imports.rs

+    }
+}
+
+// Generates a suggestion for a glob import using only the actually used items.


Suggested change

// Generates a suggestion for a glob import using only the actually used items.

/// Generates a suggestion for a glob import using only the actually used items.

ada4a · 2025-10-11T16:42:23Z

tests/ui/into_iter_on_ref.fixed


 struct X;
-use std::collections::*;
+use std::collections::{BTreeMap, BTreeSet, BinaryHeap, HashMap, HashSet, LinkedList, VecDeque};


I imagine the suggestion was quite long in this case. Because of that, I think it would make sense to give a Diag::span_suggestion_verbose (inside span_lint_and_then)

ada4a · 2025-10-11T16:44:13Z

clippy_lints/src/wildcard_imports.rs

+            } else if is_std_import(use_path.segments) {
+                (
+                    STD_WILDCARD_IMPORTS,
+                    format!("usage of wildcard import from `{}`", use_path.segments[0].ident),


nit: you could make these into Cows to avoid allocating a String in 2 out of 3 cases

ada4a · 2025-10-11T16:44:50Z

clippy_lints/src/wildcard_imports.rs

+    /// bar();
+    /// let _ = Rc::new(5);
+    /// ```
+    #[clippy::version = "1.89.0"]


Just a bit of churn^^

Suggested change

#[clippy::version = "1.89.0"]

#[clippy::version = "1.92.0"]

alanbondarun force-pushed the std_wildcard_imports branch 4 times, most recently from 3a0a721 to 5f8b8e3 Compare May 27, 2025 09:40

alanbondarun marked this pull request as ready for review May 27, 2025 09:43

rustbot assigned llogiq May 27, 2025

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label May 27, 2025

alanbondarun changed the title ~~[WIP] Add new lint: std_wildcard_imports~~ Add new lint: std_wildcard_imports May 27, 2025

This comment has been minimized.

Sign in to view

alanbondarun force-pushed the std_wildcard_imports branch from 5f8b8e3 to 80ac147 Compare June 2, 2025 12:36

llogiq requested changes Jun 2, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties labels Jun 2, 2025

tgross35 mentioned this pull request Jun 17, 2025

upstream globs + other globs should be linted on rust-lang/rust#142448

Open

jieyouxu reviewed Jun 18, 2025

View reviewed changes

alanbondarun force-pushed the std_wildcard_imports branch from 80ac147 to de87094 Compare June 24, 2025 11:54

Add new lint: std_wildcard_imports

4c4c928

alanbondarun force-pushed the std_wildcard_imports branch from de87094 to 4c4c928 Compare June 24, 2025 12:06

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties and removed S-waiting-on-author Status: This is awaiting some action from the author. (Use `@rustbot ready` to update this status) labels Jun 24, 2025

ada4a requested changes Oct 11, 2025

View reviewed changes

samueltardieu added the needs-fcp PRs that add, remove, or rename lints and need an FCP label Oct 17, 2025

		/// Wildcard imports can pollute the namespace. This is especially bad when importing from the
		/// standard library through wildcards:

	// Returns the entire span for a given glob import statement, including the `*` symbol.
	/// Returns the entire span for a given glob import statement, including the `*` symbol.

	// Generates a suggestion for a glob import using only the actually used items.
	/// Generates a suggestion for a glob import using only the actually used items.

Conversation

alanbondarun commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TODO

Uh oh!

rustbot commented May 27, 2025

Uh oh!

This comment has been minimized.

llogiq left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jun 4, 2025

Uh oh!

jieyouxu Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alanbondarun commented Jun 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

alanbondarun commented May 22, 2025 •

edited

Loading

jieyouxu Jun 18, 2025 •

edited

Loading