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

Should public_private_dependencies consider unreachable visibility? #130079

Open
ehuss opened this issue Sep 7, 2024 · 0 comments
Open

Should public_private_dependencies consider unreachable visibility? #130079

ehuss opened this issue Sep 7, 2024 · 0 comments
Labels
C-bug Category: This is a bug. F-public_private_dependencies feature: public_private_dependencies L-public_private_dependencies Lint: public_private_dependencies T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@ehuss
Copy link
Contributor

ehuss commented Sep 7, 2024

I tried this code:

mod foo {
    pub fn example() -> regex::Regex {
        regex::Regex::new("test").unwrap()
    }
}

pub fn x() {
    foo::example();
}

with cargo's public-dependency feature enabled, and regex is a private dependency.

I expected to see this happen: No warning

Instead, this happened: Generated a warning about the dependency in a public interface, but there is no exposure of the dependency in the public interface.

warning: type `regex::Regex` from private dependency 'regex' in public interface
 --> src/lib.rs:2:5
  |
2 |     pub fn example() -> regex::Regex {
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(exported_private_dependencies)]` on by default

In #44663 (comment), bjorn3 mentioned:

We consider any pub item to be public, even if not actually reachable. This is also why for example mod sealed { pub trait Sealed {} } pub trait MyTrait: Sealed {} is allowed despite Sealed not being reachable.

However, I'm not sure I completely agree with that reasoning. In the example above, there is no exposure of the private dependency in any types. This would make more sense if unreachable-pub was on by default, but it's not. Although I can sympathize that unreachable pub is probably bad form, it is very common in Rust code and would be a significant hurdle for false-positives of exported_private_dependencies.

Meta

rustc 1.83.0-nightly (9c01301c5 2024-09-05)
@ehuss ehuss added C-bug Category: This is a bug. F-public_private_dependencies feature: public_private_dependencies labels Sep 7, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Sep 7, 2024
@jieyouxu jieyouxu added L-public_private_dependencies Lint: public_private_dependencies T-lang Relevant to the language team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Sep 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. F-public_private_dependencies feature: public_private_dependencies L-public_private_dependencies Lint: public_private_dependencies T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants