-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
effective visibilities: Count types leaked through trivial type aliases as reexported #120146
Labels
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
A-visibility
Area: Visibility / privacy
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
L-unnameable_types
Lint: unnameable_types
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
label
Jan 19, 2024
This was referenced Jan 19, 2024
fmease
added
A-visibility
Area: Visibility / privacy
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
and removed
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
labels
Jan 23, 2024
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Apr 8, 2024
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.
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 8, 2024
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-lint
Area: Lints (warnings about flaws in source code) such as unused_mut.
A-visibility
Area: Visibility / privacy
C-enhancement
Category: An issue proposing an enhancement or a PR with one.
L-unnameable_types
Lint: unnameable_types
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
In the example above
struct A
will be marked as reexported, butstruct B
will only be marked as reachable.(This can be tested with
#[rustc_effective_visibility]
attribute.)It may make sense to consider
B
reexported too, because there's not much difference between ause
item and a trivial type alias.This will remove some part of false positives from the
unnameable_types
lint in particular, becauseB
is clearly nameable here.The "promotion" to reexported should only happen when the alias is trivial - no generic parameters/where-clauses/bounds/etc, the RHS should also be a module-relative path without any generic arguments, including implicit ones.
There may be some unexpected consequences from doing this change.
For example, some import inlining code in rustdoc may assume that if
B
is reexported, then a reexport chain leading toB
exists.(Need to implement the change and see what breaks.)
This is a follow up to #48054.
The text was updated successfully, but these errors were encountered: