`exported_private_dependencies` lint ignores const generics

[mladedav]

Code

use ::priv_dep::NUM; // private dependency

pub struct U<const X: u8>;
pub fn foo(_: U<NUM>) {}

Current output

No lint generated

Desired output

error: constant `NUM` from private dependency 'priv_dep' in public interface
  --> $DIR/file.rs:0:0
   |
LL | pub fn foo(_: U<NUM>) {}
   |                 ^^^

Rationale and extra context

We're linting on the same thing if it's normal generic instead of const generic. I believe this exposes the private dependency because it could change the constant which would change our public interface.

Similar issue for const generics also exist in reexports of const generic structs, implementations on those structs, implementation of const generic traits and so on.

The re-export lint correctly identifies constants from private dependencies.

Other cases

Rust Version

master

Anything else?

Tracking issue for the lint #44663

@rustbot label +F-public_private_dependencies +L-exported_private_dependencies +A-lints +A-visibility

Changes to this lint are currently reviewed in #160726 but it doesn't change this.

[lsunsi]

I'd like to help with this one, but I'd need some guidance on where to start.
It's my understanding that we want a new error happening where previously there is none, right?
I copied the example and it compiles but it shouldn't. Is that right?

PS: I won't claim the issue right away because I wanted to understand better if I could pull it off.

[petrochenkov]

In the regular private-in-public lints this is intentionally not reported, because specific values of constants are not considered parts of interfaces, and things like "private integer value" do not exist in the current privacy model.

[mladedav]

I thought this would be the same case as when the function argument type changed because we upgraded a private dependency. But I'll trust your judgment here and close this.

Also, in the context of the lint rework, I also wouldn't say that we have "private std types" but if crate A does pub use std::time::Duration; and then another crate puts A::Duration into its own API, it would be considered as having A in public API. I just wanted to mention it since I saw the parallel there, but if that's an issue, that should be discussed in the PR I guess.

[petrochenkov]

This may make more sense in exported_private_dependencies than in private-in-public lints, I'm just saying that the logic for these two kinds lints will need to diverge in that case.