Tracking Issue for future-incompatibility lint `ambiguous_import_visibilities`
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.2k
- PR merge metrics
- PR metrics pending
Description
This is the tracking issue for the ambiguous_import_visibilities future-compatibility warning and other related errors. The goal of this page is to describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.
What is the warning for?
The ambiguous_import_visibilities lint detects imports that should report ambiguity errors due to ambiguous import visibilities, but previously didn't do that due to rustc bugs.
Why was this change made?
Explain why this change was made. If there is additional context, like an MCP, link it here.
Example
mod reexport {
mod m {
pub struct S {}
}
macro_rules! mac {
() => { use m::S; }
}
pub use m::*;
mac!();
pub use S as Z; // ambiguous visibility
}
Previous versions of rustc compiled it successfully because they fetched the glob import's visibility for pub use S as Z import, and ignored the private use m::S import that appeared later.
Recommendations
Try disambiguating with explicit (non-glob) imports.
When will this warning become a hard error?
If known, describe the future plans. For example, how long you anticipate this being a warning, or if there are other factors that will influence the anticipated closure.
Steps
- Implement the lint
- Raise lint level to deny
- Change the lint to report in dependencies
- Switch to a hard error
Implementation history
- https://github.com/rust-lang/rust/pull/149596 - the lint was implemented
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the tracking issue and the implementation history link to rust-lang/rust#149596, then review the warning's policy context and existing compiler documentation. Fill in why the change was made and the expected timeline for raising or changing the lint, and ensure the example, recommendations, and checklist accurately describe the completed work.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, documentation
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 45/100