Type alias can be used to bypass privacy check

[seanmonstar]

struct Priv;

pub use self::private::public;

mod private {
    pub type Priv = super::Priv;

    pub fn public(_x: Priv) {
    }
}

The function public is exported, accepting the type Priv, even though Priv is not exported.

[alexcrichton]

triage: I-nominated

cc @nrc, @rust-lang/lang

[alexcrichton]

The workings around this were always a little subtle to me, so I'm not 100% sure if this is working as intended or just a bug where we didn't follow a type where we should.

Note that a fix for this (if we want one) is likely to have a lot of fallout so we'd definitely want to run it through crater to select a mitigation strategy.

[sfackler]

core-foundation-rs uses this to define opaque pointer type definitions for FFI bindings: https://github.com/servo/core-foundation-rs/blob/master/src/array.rs#L42-L44, so there will be some fallout to take care of if the logic is updated.

[nrc]

I think this (that a type alias can increase visibility) is a feature, not a bug. The fact that we can re-export functions without re-exporting all the types they refer to is unfortunate, but kind of intentional. The last time this kind of thing was discussed, we decided that we would not try to be complete in the checking of private types in public signatures, since it is way too complex and we'd only try to enforce a syntactic distinction, rather than taking reachability, etc. into account.

[arielb1]

@sfackler

This does not, in fact, offer any real protection:

trait Pointer { type Pointee; }
impl<T:?Sized> Pointer for *const T { type Pointee = T; }
type __CFArray = <CFArrayRef as Pointer>::Pointee;

[alexcrichton]

@nrc yeah that was my vague recollection as well, but I thought the rule we were going for was "if this isn't pub you know it's not reachable", which isn't true in this example.

[nikomatsakis]

I would expect a pub type Foo = Bar to enforce the same rules as pub use Bar or pub fn f(b: Bar).

[eefriedman]

@nikomatsakis See 859277d#diff-da2bd5399ed4e70e4df4ef04a88d0d9cR1344 . CC @huonw.

[nikomatsakis]

thematically related to #28325, at least

[nikomatsakis]

triage: P-high -- backwards compat