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

A strange processing methods visibility #22684

Closed
bozaro opened this issue Feb 22, 2015 · 8 comments · Fixed by #31938
Closed

A strange processing methods visibility #22684

bozaro opened this issue Feb 22, 2015 · 8 comments · Fixed by #31938
Labels
A-type-system Area: Type system P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@bozaro
Copy link

bozaro commented Feb 22, 2015

rustc 1.0.0-nightly (2b01a37 2015-02-21) (built 2015-02-22)

I create file with content:

use std::hash::SipHasher;
use std::hash::Hasher;

fn main() {
}

fn compile_fail() {
    let hasher = SipHasher::new();
    hasher.write(&[0, 1, 2]);
}

fn compile_work() {
    let sip_hasher = SipHasher::new();
    let hasher: &mut Hasher = &mut sip_hasher;
    hasher.write(&[0, 1, 2]);
}

And have compilation errors:

private.rs:9:2: 9:26 error: method `write` is private
private.rs:9    hasher.write(&[0, 1, 2]);
                ^~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

I do not understand what is happening due to this error, because this cast is essentially doing nothing.

@steveklabnik steveklabnik added the A-type-system Area: Type system label Feb 23, 2015
@edwardw
Copy link
Contributor

edwardw commented Feb 24, 2015

SipHasher has both a private write method and a public one implemented in Hasher trait for it. The former shadows the later. Probably related to #12808.

@edwardw
Copy link
Contributor

edwardw commented Feb 24, 2015

This is rather confusing from user's point of view. Because by definition, a private method doesn't show up in the rustdoc. So looking up rustdoc doesn't help diagnosing this particular error.

I wonder what is the optimal solution here. Maybe an help message of some sort?

@steveklabnik
Copy link
Member

I've created a self-contianed example of this behavior:

mod foo {
    pub struct Foo;

    impl Foo {
        fn bar(&self) {
            println!("private bar in foo");
        }
    }

    pub trait Baz {
        fn bar(&self);
    }

    impl Baz for Foo {
        fn bar(&self) {
            println!("public bar in foo from Baz");
        }
    }
}

fn main() {
    let mut f = foo::Foo;
    f.bar(); // doesn't work

    let b: &mut foo::Baz = &mut f;

    b.bar(); // works
}

/cc @rust-lang/lang . I am not sure that this is fixible? It would seem like a big change to modify these rules.

@aturon aturon added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Mar 7, 2016
@aturon
Copy link
Member

aturon commented Mar 7, 2016

Nominating for discussion at next lang team meeting.

@nikomatsakis
Copy link
Contributor

As @edwardw said, this is (to my mind) the same "FIXME" as #12808 (which just talks about fields). I think we can probably change this, because we'd just be making more code compile, but I've not thought super hard about that.

@nikomatsakis
Copy link
Contributor

In @rust-lang/lang meeting we decided that this should indeed follow the same lookup rules as #12808.

@nikomatsakis
Copy link
Contributor

triage: P-medium

@nikomatsakis nikomatsakis added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. P-medium Medium priority labels Mar 10, 2016
@jseyfried
Copy link
Contributor

@nikomatsakis This is fixed in the above PR -- I'll add @steveklabnik's example as a test.

jseyfried added a commit to jseyfried/rust that referenced this issue Mar 16, 2016
jseyfried added a commit to jseyfried/rust that referenced this issue Mar 30, 2016
bors added a commit that referenced this issue Mar 31, 2016
Integrate privacy into field and method selection

This PR integrates privacy checking into field and method selection so that an inaccessible field/method can not stop an accessible field/method from being used (fixes #12808 and fixes #22684).
r? @eddyb
bors added a commit that referenced this issue Mar 31, 2016
Integrate privacy into field and method selection

This PR integrates privacy checking into field and method selection so that an inaccessible field/method can not stop an accessible field/method from being used (fixes #12808 and fixes #22684).
r? @eddyb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants