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

effective visibilities: Count types leaked through trivial type aliases as reexported #120146

Open
petrochenkov opened this issue Jan 19, 2024 · 0 comments
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

@petrochenkov
Copy link
Contributor

mod m {
    pub struct A {}
    pub struct B {}
}

pub use m::A as U;
pub type V = m::B;

In the example above struct A will be marked as reexported, but struct 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 a use item and a trivial type alias.
This will remove some part of false positives from the unnameable_types lint in particular, because B 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 to B exists.
(Need to implement the change and see what breaks.)

This is a follow up to #48054.

@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Jan 19, 2024
@fmease 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.
@jieyouxu jieyouxu added the L-unnameable_types Lint: unnameable_types label May 13, 2024
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.
Projects
None yet
Development

No branches or pull requests

4 participants