privacy exposure bug when mixing explicit type ascription and an impl on struct

[pnkfelix]

Surely adding a type ascription shouldn't cause a privacy violation, right? And yet...

Example file (a.rs):

mod a {
    struct S;

    #[cfg(not(hide_impl))]
    impl S { }

    pub struct Expose;
    impl Expose { pub fn expose(&self) -> S { S } }
}

fn f_infer() {
    let _s;
    _s = a::Expose.expose();
}

#[cfg(demo_explicit)]
fn f_typed() {
    let _s : a::S;
    _s = a::Expose.expose();
}

fn main() {}

Some runs illustrating the bug. Note that the only difference introduced by hide_impl is whether or not the empty impl item for S is present, and therefore toggling it should not (IMO) be causing changes to the privacy semantics.

% rustc a.rs
% rustc --cfg demo_explicit a.rs
% rustc --cfg hide_impl a.rs
% rustc --cfg hide_impl --cfg demo_explicit a.rs
a.rs:18:13: 18:17 error: type `S` is private
a.rs:18     let _s : a::S;
                     ^~~~
error: aborting due to previous error
task 'rustc' failed at 'explicit failure', /Users/fklock/Dev/Mozilla/rust.git/src/libsyntax/diagnostic.rs:101
task '<main>' failed at 'explicit failure', /Users/fklock/Dev/Mozilla/rust.git/src/librustc/lib.rs:396

(Possibly related to #10545, but do note that the properties of these two scenarios do differ. In particular, the presence/absence of fields in the struct seems to be irrelevant for this bug.)

[alexcrichton]

If anything is the bug here, it's that we're letting a return value be a private struct. It's already a little weird that we allow that, and it may be too unreasonable to disallow that. I believe that the privacy checker is correct in disallowing usage of a::S as a type (or a value as well), and I personally think that it's fine to return a private struct, you're just understanding that it's quite limiting on callers (because they can't really do a whole lot with it.

[pnkfelix]

@alexcrichton yeah, the only use case I can think of for a pub function returning a private struct would be for chaining it together with another pub function that consumes that struct.

But its still weird to mark the type ascription as disallowed. Could it make more sense to disallow binding the intermediate value itself? (Basically forcing the client code to perform such chaining?) I'm really just thinking out loud right now, not sure if I actually would like having to work with such a rule.

(Having said that, I'm tempted to just say that we should just force any struct used for argument or return type on a pub fn to also be pub.)

[pcwalton]

This seems like the correct behavior to me. Privacy is about the ability to name things in Rust; adding a name causes privacy to be checked.

[alexcrichton]

This is a bug in privacy actually (a little confusing from the description), but this program should not compile (and it does)

mod a {
    struct S;
    impl S { }
}

fn foo(_: a::S) {
}

fn main() {}

This program should not be able to name a::S. That being said, I believe that this is the only bug that this issue should be referencing.

[alexcrichton]

Closing as a dupe of #10545, my test case is essentially what's going on in that bug, and otherwise I believe everything is working as intended.