Description
Proposal
"Where is this thing used?" is a question I ask all the time when reading unfamiliar code. Because of this, I generally find it annoying when things are marked with a more permissive visibility than necessary. "This thing marked pub, which other crates is it used in? Oh, it's not used in any other crates."
I have downgraded/removed unecessarily permissive visibilities for many things in many PRs, because I think it genuinely helps with readability. Having automated assistance to catch some cases would be very helpful, and that's what deny(unreachable_pub) provides.
The comment describe the unreachable_pub is quite informative:
/// The `unreachable_pub` lint triggers for `pub` items not reachable from other crates - that
/// means neither directly accessible, nor reexported, nor leaked through things like return
/// types.
///
/// ### Example
///
/// ```rust,compile_fail
/// #![deny(unreachable_pub)]
/// mod foo {
/// pub mod bar {
///
/// }
/// }
/// ```
///
/// {{produces}}
///
/// ### Explanation
///
/// The `pub` keyword both expresses an intent for an item to be publicly available, and also
/// signals to the compiler to make the item publicly accessible. The intent can only be
/// satisfied, however, if all items which contain this item are *also* publicly accessible.
/// Thus, this lint serves to identify situations where the intent does not match the reality.
///
/// If you wish the item to be accessible elsewhere within the crate, but not outside it, the
/// `pub(crate)` visibility is recommended to be used instead. This more clearly expresses the
/// intent that the item is only visible within its own crate.
///
/// This lint is "allow" by default because it will trigger for a large
/// amount existing Rust code, and has some false-positives. Eventually it
/// is desired for this to become warn-by-default.
rust-lang/rust#126013 is a draft PR that adds this lint to a subset of the rustc_* crates, which gives a good idea of the effect. Lots of pubs get downgraded to pub(crate) (or pub(super)), and some pub/pub(crate)/pub(super)s are removed entirely.
Mentors or Reviewers
None.
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.