super trait and trait object error with "source trait is inaccessible", but source trait is in scope (via a reexport)

[japaric]

STR

use array::ArrayShape;

pub mod array {
    pub use self::traits::ArrayShape;

    mod traits {
        pub trait ArrayShape {
            fn shape(&self) -> (usize, usize) {
                (0, 0)
            }
        }
    }
}

struct Array;

impl ArrayShape for Array {}

fn main() {
    println!("{:?}", Array.shape());  //~ error: source trait is inaccessible
}

trait MatrixShape: ArrayShape {
    fn nrows(&self) -> usize { self.shape().0 }  //~ error: source trait is inaccessible
}

fn show() {
    println!("{:?}", (&Array as &ArrayShape).shape());  //~ error: source trait is inaccessible
}

Version

rustc 1.0.0-nightly (458a6a2f6 2015-01-25 21:20:37 +0000)

---

Original issue

STR

use array::ArrayShape;

pub mod array {
    pub use self::traits::ArrayShape;

    mod traits {
        pub trait ArrayShape {
            fn shape(&self) -> (uint, uint) {
                (0, 0)
            }
        }
    }
}

struct Array;

// `ArrayShape` is available in this scope, it can be implemented ...
impl ArrayShape for Array {}

fn main() {
    // ... and can also be used
    println!("{}", Array.shape());
}

// But this super trait doesn't work
#[cfg(not(working))]
trait MatrixShape: ArrayShape {
    fn nrows(&self) -> uint { self.shape().val0() }
}

#[cfg(not(working))]
fn bad() {
    // This doesn't work either
    println!("{}", (&Array as &ArrayShape).shape());
}

Output:

trait.rs:28:31: 28:43 error: source trait is inaccessible
trait.rs:28     fn nrows(&self) -> uint { self.shape().val0() }
                                          ^~~~~~~~~~~~
trait.rs:28:31: 28:43 note: module `traits` is private
trait.rs:28     fn nrows(&self) -> uint { self.shape().val0() }
                                          ^~~~~~~~~~~~
trait.rs:34:20: 34:51 error: source trait is inaccessible
trait.rs:34     println!("{}", (&Array as &ArrayShape).shape());
                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: in expansion of format_args!
<std macros>:2:23: 2:77 note: expansion site
<std macros>:1:1: 3:2 note: in expansion of println!
trait.rs:34:5: 34:53 note: expansion site
trait.rs:34:20: 34:51 note: module `traits` is private
trait.rs:34     println!("{}", (&Array as &ArrayShape).shape());
                               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
note: in expansion of format_args!
<std macros>:2:23: 2:77 note: expansion site
<std macros>:1:1: 3:2 note: in expansion of println!
trait.rs:34:5: 34:53 note: expansion site
error: aborting due to 2 previous errors

I'm no longer sure if this is a bug or is intended? The impl block works, but the super trait and the trait object don't. Do the latter two have different scoping/privacy rules?

Version:

rustc 0.12.0-pre (795f6ae82 2014-08-04 07:01:10 +0000)

[steveklabnik]

This now gives "expected function, found usize" :/

[japaric]

I've updated the top comment code to rust nightly, and at least now we are getting a more consistent answer from the compiler; all the uses of the ArrayShape trait are rejected with "inaccessible source trait".

What I'm not sure about is if the impl ArrayShape for Array {} should be accepted given that it occurrs in the root of the crate, where the trait is supossed to be inaccessible.

Maybe @alexcrichton can confirm if that's the intended behaviour?

[alexcrichton]

This definitely seems like suspicious behavior to me, I would expect no errors from the code above. I suspect that the privacy checks for traits is a little wonky and not seeing the reexport.

[mahkoh]

Still an issue.

[zummenix]

I have a similar example:

use core::Check;

fn main() {
    let x = Value;
    x.check();
}

struct Value;

impl Check for Value {
    fn check(&self) -> bool {
        true
    }
}

pub mod core {
    pub use self::private::Check;
    mod private {
        pub trait Check {
            fn check(&self) -> bool;
        }
    }
}

Only acceptable fix for me is to move the Check trait to the core level.

[ihrwein]

Still an issue with stable 1.0. Making public the private module is a workaround.

[ghost]

Ran into this issue today and noticed something odd, this only seems to happen when trying to use the "private" trait internally. Created a small test repo to demonstrate: Eljay/trait_privacy_test@6a9fc6a

The Bar trait from the inner crate is accessible from the main crate, and from the test_baz_external test in the tests folder (I guess these are technically the same but testing both anyway).

However, the inline test in inner\src\lib.rs fails with the error:

inner\src\lib.rs:17:5: 17:12 error: source trait is inaccessible
inner\src\lib.rs:17     y.baz();
                        ^~~~~~~
inner\src\lib.rs:17:5: 17:12 note: module `bar` is private
inner\src\lib.rs:17     y.baz();
                        ^~~~~~~

Tested on stable 1.0.0 and latest nightly.

[dbrgn]

Same issue here. Any solutions? Is this intended behavior?

I'd prefer not making my submodules containing traits public, as that is an implementation detail. I'd rather re-export the trait from the mod.rs file.

[IvanUkhov]

I also would be grateful for an update on the issue. Thanks!

Regards,
Ivan

[ticki]

Still a problem in rustc stable 1.2.0.

[bluss]

One workaround is calling using explicit Trait::method syntax.