Note message after error recommends using inaccessible private fields.

[Nashenas88]

The following code:

pub mod animal {
    pub struct Dog {
        pub age: usize,
        dog_age: usize,
    }

    impl Dog {
        pub fn new(age: usize) -> Dog {
            Dog { age: age, dog_age: age * 7 }
        }
    }
}

fn main() {
    let dog = animal::Dog::new(3);
    let dog_age = dog.dog_age();
    //let dog_age = dog.dog_age;
    println!("{}", dog_age);
}

Outputs the following message:

<anon>:16:23: 16:32 error: no method named `dog_age` found for type `animal::Dog` in the current scope
<anon>:16     let dog_age = dog.dog_age();
                                ^~~~~~~~~
<anon>:16:23: 16:32 note: did you mean to write `dog.dog_age`?
<anon>:16     let dog_age = dog.dog_age();
                                ^~~~~~~~~
error: aborting due to previous error

However, correcting the code by following the note message causes the following output:

<anon>:17:19: 17:30 error: field `dog_age` of struct `animal::Dog` is private
<anon>:17     let dog_age = dog.dog_age;
                            ^~~~~~~~~~~
error: aborting due to previous error

I would expect the private field to not be recommended.

[Aatch]

That's unfortunate. We should be able filter out fields that aren't accessible due to privacy though.

[Nashenas88]

@Aatch, from my conversations with @eddyb, this will be dependent on #12808. Currently there's no simple way to check privacy in the pass that generates this message.

[eddyb]

@Nashenas88 IIRC, the privacy check is really simple, but the privacy checker pass needs to be ported to use the parent IDs found in the ast_map instead of computing its own.
After that, the algorithm could be extracted and made available in rustc::middle::privacy, for all passes to use (as long as they have access to an ast_map).

[Nashenas88]

@eddyb, I didn't have too much time to play around with the privacy checker pass this weekend, but I did try to port it to use the parent IDs in the ast_map with no luck. The compiler gets stuck in an infinite loop. I tried both ast_map::get_parent and ast_map::get_parent_node. Looking at the ParentVisitor, it seems to build up parents differently than the ast_map. It uses the same word, but seems to focus on the privacy scope when determining its definition of parent. I'll have to take a closer look at how the ast_map builds up the parents. My initial guess is that it's different enough that swapping out the ParentVisitor won't be such a simple task.

[eddyb]

@Nashenas88 the ast_map is a forest, with the roots being either the local crate, or inlined items.
The get_parent(id) method will return the same id if the root has been reached, which is presumably where your infinite loop comes from.

[eddyb]

I guess the doc comment on get_parent is a bit vague about it, though it does mention that it will return the same ID when there is no parent (instead of some magic value).

[steveklabnik]

Triage; no change