-
Notifications
You must be signed in to change notification settings - Fork 12.5k
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
privacy: Stabilize lint unnameable_types
#120144
Conversation
r? @davidtwco (rustbot has picked a reviewer for you, use r? to override) |
cc @Bryanskiy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks good to me, r=me after relevant sign-offs.
We talked about this in today's @rust-lang/lang meeting. We're in favor of shipping this. Some of us were favorable towards making it warn-by-default in the future. We had one suggestion for naming and application of this lint: if we fired the lint specifically at the point where you are applying a non-pub visibility to a module with pub items, and called the lint something like |
We discussed this in the lang triage meeting today. There was lots of discussion about the exact details of the lint, but general agreement that as allow-by-default we should let people start trying this so that they can give feedback about what it reports and how. @rfcbot fcp merge Some of the topics that came up were about potentially linting on the module that "hides" the things inside it instead of on the items hidden, what the right way to suppress this when needed would be, and why macros might be generating things as But as far as I could tell, none of those seemed like blockers for this PR making the lint available to people, just that people might potentially have concerns should a future PR propose moving it to warn-by-default, depending on details. |
Team member @scottmcm has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. |
I do think we should consider renaming this to |
@rustbot labels -I-lang-nominated As evidenced by the discussion above, we discussed this on the lang call today, and while there was discussion about where to go from here, no one seemed opposed to stabilizing an allow-by-default lint. The outcome is the proposed FCP merge, so we can unnominate this. Thanks to @petrochenkov for pushing this forward. |
What you are describing here looks like another already existing allow-by-default lint -
|
@petrochenkov It sounds like you are using a definition of "reachable" that is different from what I understood the term to mean (which is the same as how you are using "nameable"). Explaining the terms in error messages and docs would help. My feeling is that we should just redefine |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks good to me, r=me once lang discussions resolved.
This comment was marked as resolved.
This comment was marked as resolved.
The `private_in_public` rustc lint is now deprecated and throws a warning on each `cargo check`. According to the rfc [0] this lint is being substituted by three other ones: `private_interfaces`, `private_bounds` and `unnameable_types`. `unnameable_types` is not yet stabilized [1], so it will throw a warning, but we will be ready when it is :) [0]: https://rust-lang.github.io/rfcs/2145-type-privacy.html [1]: rust-lang/rust#120144
I used the naming used in the compiler (
Also
|
So, summarizing again:
|
I've updated some lint docs. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Already reviewed the implementation and the FCP has finished, so will approve this now. @bors r+ |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#115984 (extending filesystem support for Hermit) - rust-lang#120144 (privacy: Stabilize lint `unnameable_types`) - rust-lang#122807 (Add consistency with phrases "meantime" and "mean time") - rust-lang#123089 (Add invariant to VecDeque::pop_* that len < cap if pop successful) - rust-lang#123595 (Documentation fix) - rust-lang#123625 (Stop exporting `TypeckRootCtxt` and `FnCtxt`.) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#120144 - petrochenkov:unty, r=davidtwco privacy: Stabilize lint `unnameable_types` This is the last piece of ["RFC rust-lang#2145: Type privacy and private-in-public lints"](rust-lang#48054). Having unstable lints is not very useful because you cannot even dogfood them in the compiler/stdlib in this case (rust-lang#113284). The worst thing that may happen when a lint is removed are some `removed_lints` warnings, but I haven't heard anyone suggesting removing this specific lint. This lint is allow-by-default and is supposed to be enabled explicitly. Some false positives are expected, because sometimes unnameable types are a legitimate pattern. This lint also have some unnecessary false positives, that can be fixed - see rust-lang#120146 and rust-lang#120149. Closes rust-lang#48054.
I have been playing with adding Having said that, I do have one suggestion:
A bit tedious, and would have been a lot easier if the lint could distinguish the two cases. |
This is the last piece of "RFC #2145: Type privacy and private-in-public lints".
Having unstable lints is not very useful because you cannot even dogfood them in the compiler/stdlib in this case (#113284).
The worst thing that may happen when a lint is removed are some
removed_lints
warnings, but I haven't heard anyone suggesting removing this specific lint.This lint is allow-by-default and is supposed to be enabled explicitly.
Some false positives are expected, because sometimes unnameable types are a legitimate pattern.
This lint also have some unnecessary false positives, that can be fixed - see #120146 and #120149.
Closes #48054.