`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.

[mladedav]

I've done a little bit more digging and found this list of items that are undecided whether they constitute a breaking change or not which includes changing constant values and this short thread where someone raised it earlier.

If it's not considered a breaking change then the lint probably should not fire by default on constants.

Or the line for breaking changes in constants is as clear as that if something can conceivably be part of a type (e.g. const ARRAY_LEN: usize) then should be considered a breaking change and if it's to be used only as a value (e.g. const VERSION: u8) then it's not a breaking change. Which would mean that just by seeing the constant inside a type, it's obviously the first case and we can fire the lint.

With that said it seems to me like the discussion is actually a bit broader so that should be decided first and then the behavior of this specific lint should follow after that. So for now, there's nothing to be done here.