turn on clippy::wildcard_imports

[OmarTawfik]

cc @Xanewok for context: #680 (comment)

This works well on use foo::* and allows automatic fixing/replacing. But it doesn't work on pub use foo::*. I looked into doing that manually, but realized that for public re-exports, it is actually much more work to do/maintain than the readability benefits it offers, especially when items have different visibility, and there are generated items.

Taking non_terminals/mod.rs, I think the below list is a lot of noise, and requires manual work every time we add/remove something. I suggest allowing pub use foo::* for these reasons, and use it as appropriate.

pub use enum_::{EnumItem, EnumVariant};
pub use field::{Field, FieldDelimiters, FieldKind, FieldsErrorRecovery};
pub use precedence::{PrecedenceExpression, PrecedenceItem, PrecedenceOperator, PrimaryExpression};
pub use repeated::RepeatedItem;
pub use separated::SeparatedItem;
pub use struct_::StructItem;

pub(crate) use enum_::{SpannedEnumItem, SpannedEnumVariant};
pub(crate) use field::{
    SpannedField, SpannedFieldDelimiters, SpannedFieldKind, SpannedFieldsErrorRecovery,
};
pub(crate) use precedence::{
    SpannedPrecedenceExpression, SpannedPrecedenceItem, SpannedPrecedenceOperator,
    SpannedPrimaryExpression,
};
pub(crate) use repeated::SpannedRepeatedItem;
pub(crate) use separated::SpannedSeparatedItem;
pub(crate) use struct_::SpannedStructItem;

[changeset-bot]

⚠️ No Changeset found

Latest commit: 5cebd98

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Xanewok]

and there are generated items

Like I said at some point, pub-use-glob has use cases and the one with generated items is definitely fitting; however, there are many other places across the codebase where explicitly exporting items would be more fitting, instead.

Regardless of that, import globs are also not ideal, especially super::* (if not used in inline modules). It's great that we're now linting against that, thanks!