You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Improve "private type in public interface" message #50430
There seems to be an issue with detecting the pub-ness of types on the current nightly (EDIT: and actually stable) branch. Consider the following code:
main.rs:
mod hardware;fnmain(){
hardware::do_stuff();}
hardware/mod.rs:
mod parser;#[derive(Debug)]structHardware{foo:u32}pubfndo_stuff(){let hw = parser::get_hardware();println!("{:?}", hw);}
Around the time of this issue report, the error message looked like this:
error[E0446]: private type `hardware::Hardware` in public interface
--> 50430.rs:5:9
|
5 | / pub fn get_hardware() -> Hardware {
6 | | Hardware { foo: 5 }
7 | | }
| |_________^ can't leak private type
As part of #51866 (c2d44b2), the message was expanded to include the span of the definition of the private type:
error[E0446]: private type `hardware::Hardware` in public interface
--> src/main.rs:5:9
|
5 | / pub fn get_hardware() -> Hardware {
6 | | Hardware { foo: 5 }
7 | | }
| |_________^ can't leak private type
...
11 | struct Hardware {
| - `hardware::Hardware` declared as private
What's happening internally is that we're looking up the visibility modifier on the HIR node corresponding to the definition of a type, and linting if it's less visible than its parent (in the sense that a return type is the child of a function signature in the relevant traversal). In this example, the problem is that if the parser module is visible, then its public function parser::get_hardware is visible, but its return type isn't, and that's not allowed.
@spacekookie In what way do you think the current error message could be improved? (I guess we could add two maybe-incorrect suggestions to either make the private type more visible, or make the function less visible??) cc @estebank
Even if we don't change anything about the heuristics, we could extend @zackmdavis' PR to also suggest the appropriate visibility annotation that would make it compile.
Also stumbled onto this problem. The error message is really confusing and initially I started creating bug report only to find out that this is the expected behaviour.
Activity
zackmdavis commentedon Aug 18, 2018
Around the time of this issue report, the error message looked like this:
As part of #51866 (c2d44b2), the message was expanded to include the span of the definition of the private type:
What's happening internally is that we're looking up the visibility modifier on the HIR node corresponding to the definition of a type, and linting if it's less visible than its parent (in the sense that a return type is the child of a function signature in the relevant traversal). In this example, the problem is that if the
parsermodule is visible, then its public functionparser::get_hardwareis visible, but its return type isn't, and that's not allowed.@spacekookie In what way do you think the current error message could be improved? (I guess we could add two maybe-incorrect suggestions to either make the private type more visible, or make the function less visible??) cc @estebank
spacekookie commentedon Aug 19, 2018
I guess what I'm wondering is if this is a bug or at least something that should really be allowed.
In case this is what's supposed to happen I'm not entirely sure how the message could be made any better though
estebank commentedon Aug 19, 2018
I believe that by default we should treat
get_hardwareaspub(super)andHardwareaspub(self)(orget_hardwareaspub(in hardware)andHardwareaspub(in hardware), which should be the same) for the purposes of this lint. It is common for some of the visibility lints to not properly account for impossibility of escape in some cases. In the end, the code as posted should behave as proposed, but ifget_hardwareispubin apub modit should emit the current error:Does this sound correct?
Even if we don't change anything about the heuristics, we could extend @zackmdavis' PR to also suggest the appropriate visibility annotation that would make it compile.
hrvolapeter commentedon Apr 12, 2020
Also stumbled onto this problem. The error message is really confusing and initially I started creating bug report only to find out that this is the expected behaviour.
I tried this code:
Playground
I expected to see this happen: Compile. Module A is not crate public so trait A is not crate public.
Instead, this happened: Compile error, private type in public interface
estebank commentedon Sep 28, 2025
None of the playground links trigger
private_in_publicnow.estebank commentedon Sep 9, 2026
Lint
private_in_publichas been removed: replaced with another group of lints: https://rust-lang.github.io/rfcs/2145-type-privacy.html