Diagnostic regression (1.47 -> 1.48): public enum fields incorrectly described as "inaccessible fields".

[eddyb]

Test example (try on playground):

mod foo {
    pub struct Pub { private: () }

    pub enum Enum {
        Variant { x: (), y: () },
        Other
    }
    
    fn correct() {
        Pub {};
        Enum::Variant { x: () };
    }
}

fn correct() {
    foo::Pub {};
}

fn wrong() {
    foo::Enum::Variant { x: () };
}

Only foo::Pub {} in the top level correct should say "cannot construct ... due to inaccessible fields", the other 3 errors should be "missing field ... in initializer", but it seems like it's treating the enum field as private (even though it inherits pub from the enum).

The "cannot construct ... due to inaccessible fields" error seems to be new in 1.48, as part of #76524, and unmodified since.

It's using field.vis.is_accessible_from(...) which seems correct, but it's possible enum fields are incapable of giving the right result, if they don't track the enum's own privacy (and they only know they inherit it, whatever it is).

cc @davidtwco @estebank

[jyn514]

I would also suspect #78077.

[camelid]

I ran into this too, but I couldn't make a repro. Thanks eddyb!

[camelid]

P-high: I've run into this a bunch of times and I imagine others have too. It's really annoying and confusing, likely even more so for newcomers!

[camelid]

searched nightlies: from nightly-2020-08-01 to nightly-2020-10-15
regressed nightly: nightly-2020-09-11
searched commits: from e2be5f5 to a1947b3
regressed commit: ad3a6f7

bisected with cargo-bisect-rustc v0.6.0

Host triple: x86_64-apple-darwin
Reproduce with:

cargo bisect-rustc --preserve --prompt --start=2020-08-01 --end=2020-10-15 

[camelid]

Seems very likely that this is due to #76524, as eddyb said.

EDIT: Though, as jyn514 suggested, the underlying bug could be #78077, which was then surfaced in #76524.