Skip to content
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

Trait visability is not consistent. #10857

Closed
HildarTheDorf opened this issue Dec 8, 2013 · 1 comment · Fixed by #10862
Closed

Trait visability is not consistent. #10857

HildarTheDorf opened this issue Dec 8, 2013 · 1 comment · Fixed by #10862
Labels
A-visibility Area: Visibility / privacy

Comments

@HildarTheDorf
Copy link

Attempting to "pub use module::privatetrait" fails with "trait is private", but it is then possible to use the trait from another crate.

// lib.rs
#[crate_type="lib"];
#[link(name="library",
       vers="0.0",
       package_id="library")];
#[feature(globs)];

//This does not export privatetrait.
pub use module::*;

//This fails with "privatetrait is private"
//pub use module::privatetrait;

pub mod module {
    trait privatetrait {
        fn private();
    }

    pub trait publictrait {
        fn public();
    }
}
// main.rs
extern mod library;

struct bugfinder;

//This does not work (and shouldn't). privatetrait is not exported
/*
impl library::privatetrait for bugfinder {
    fn private() {
    }
}
*/

//This works (and shouldn't).
impl library::module::privatetrait for bugfinder {
    fn private() {
    }
}

//This works (and should).
impl library::publictrait for bugfinder {
    fn public() {
    }
}

fn main() {
}

(lib.rs is one crate, main.rs is another.)

This was compiled with master as of 67aca9c.

@huonw
Copy link
Member

huonw commented Dec 8, 2013

Thanks for the bug report, it certainly seems wrong.

(I've inlined your gist for posterity, just in case the link goes dead.)

bors added a commit that referenced this issue Dec 10, 2013
This bug showed up because the visitor only visited the path of the implemented
trait via walk_path (with no corresponding visit_path function). I have modified
the visitor to use visit_path (which is now overridable), and the privacy
visitor overrides this function and now properly checks for the privacy of all
paths.

Closes #10857
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 2, 2023
…-doc, r=flip1995

Explain which paths clippy searches for configuration in docs

Fixes rust-lang/rust-clippy#9921.

Adds information on where to place the configuration files, it may be a bit verbose. Also added a comment to the section of the code where the search happens, to hopefully prevent changing that without updating the docs.

changelog: Make documentation about where to place configuration files clearer.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-visibility Area: Visibility / privacy
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants