Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"unused import" could be more helpful ("nothing to export") #123855

Open
arifd opened this issue Apr 12, 2024 · 1 comment
Open

"unused import" could be more helpful ("nothing to export") #123855

arifd opened this issue Apr 12, 2024 · 1 comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@arifd
Copy link

arifd commented Apr 12, 2024

Code

mod misc {
    const WOW: usize = 1;
}

pub use misc::*;

Current output

warning: unused import: `misc::*`
 --> src/main.rs:6:9
  |
6 | pub use misc::*;
  |         ^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: `playground` (bin "playground") generated 1 warning (run `cargo clippy --fix --bin "playground"` to apply 1 suggestion)

Desired output

Either an additional hint saying why this lint is complaining "There is nothing to export"

Or a new lint or something.

Rationale and extra context

In more complex codebases it's not immediately obvious what the problem is. I'd prefer a message like "nothing to export".

Other cases

No response

Rust Version

rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: aarch64-apple-darwin
release: 1.75.0
LLVM version: 17.0.6

Anything else?

No response

@arifd arifd added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 12, 2024
@eggyal
Copy link
Contributor

eggyal commented Apr 12, 2024

I dont think the issue is or diagnostic should be about what is exported here.

A wildcard use declaration that doesn't actually bind any visible paths should (probably?) error on that ground alone. This, I think, is the issue that needs addressing here.

Irrespective of any wildcard, if a use declaration is unused, that's a different error (the currently displayed one).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants