Skip to content

Rust 1.16 leaking private types out of a crate library through "pub use" #40831

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

Closed
erickt opened this issue Mar 25, 2017 · 3 comments
Closed
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@erickt
Copy link
Contributor

erickt commented Mar 25, 2017

Hello!

We found a case where it's possible to leak a private type through the use of pub use. Consider this crate with a single file buffer.rs:

mod buffer {
    pub struct EnumeratePixels;
    pub struct ImageBuffer;

    impl ImageBuffer {
        pub fn enumerate_pixels(&self) -> EnumeratePixels {
            EnumeratePixels
        }
    }
}

pub use buffer::ImageBuffer;

Rust allows it to compile, even though EnumeratePixels is not publicly exposed from root:

% rustc --crate-type lib buffer.rs
%

It's possible to then use this crate like so:

extern crate buffer;

fn main() {
    let buffer = buffer::ImageBuffer;
    let _pixels = buffer.enumerate_pixels();
}

Rust 1.16 allows this to compile:

% rustc -L . bug.rs
%

However, it's impossible to name the type of enumerate_pixels():

extern crate buffer;

fn main() {
    let buffer = buffer::ImageBuffer;
    let _pixels: buffer::buffer::EnumeratePixels = buffer.enumerate_pixels();
}

This produces:

% rustc -L . bug.rs
error: module `buffer` is private
 --> bug.rs:5:18
  |
5 |     let _pixels: buffer::buffer::EnumeratePixels = buffer.enumerate_pixels();
  |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

I suspect this bug may have been reported in a few other tickets: #33077, #39437, #38844, #39437

@erickt erickt added the A-diagnostics Area: Messages for errors, warnings, and lints label Mar 25, 2017
@Thinkofname
Copy link

This seems to be intended according to #34537 which documents using private modules to leak private types.

@petrochenkov
Copy link
Contributor

@Thinkofname is right, this is the intended behavior.

@retep998
Copy link
Member

The fact that this is intended behavior is why I'm so opposed to the current private in public rules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints
Projects
None yet
Development

No branches or pull requests

4 participants