match variant with fields unresolved when enum type in scope

[pnkfelix]

Here is some code (derived from something I actually saw recently in rustc):

pub mod a {
    pub enum E {
                         A,
                         B,
        #[cfg(show_bug)] C(int),
    }
    pub mod b {
        pub fn key(e: ::a::E) -> StrBuf {
            match e {
                                 A => "A",
                                 B => "B",
                #[cfg(show_bug)] C(_) => "C",

            }.to_strbuf()
        }
    }
}

fn main() {
    println!("Hello World {}", a::b::key(a::A));
}

Now the bug:

% rustc /tmp/e.rs && ./e
Hello World A
% rustc --cfg show_bug /tmp/e.rs && ./e
/tmp/e.rs:12:34: 12:35 error: unresolved enum variant, struct or const `C`
/tmp/e.rs:12                 #[cfg(show_bug)] C(_) => "C",
                                              ^
error: aborting due to previous error

---

(The workaround is to explicitly import the enum variant with the field. It does not suffice to just do use a::EnumType; see comments below.)

[alexcrichton]

This looks like a serious resolve bug, neither the name A or B is in scope for mod b. Nominating.

[pnkfelix]

wow I think this bug is actually much more serious than I had realized. Even doing a use a::Enum; in the inner module does not suffice to pull C into scope, though it does pull A and B into scope.

pub mod a {
    pub enum En { A,
                  B,
    #[cfg(field)] C(int) }

    pub fn key(e: En) -> StrBuf {
        match e { A => "A",
                  B => "B",
    #[cfg(field)] C(_) => "C",
        }.to_strbuf()
    }

    #[cfg(inner)]
    pub mod b {
        use a::En;
        pub fn key(e: En) -> StrBuf {
            match e { A => "A",
                      B => "B",
        #[cfg(field)] C(_) => "C",
            }.to_strbuf()
        }
    }
}

#[cfg(inner)]
fn main() {
    println!("Hello World {}", a::b::key(a::A));
}

#[cfg(not(inner))]
fn main() {
    println!("Hello World {}", a::key(a::A));
}

If you have both inner and field, things break:

% rustc /tmp/e.rs && ./e
Hello World A
% rustc --cfg inner /tmp/e.rs && ./e
Hello World A
% rustc --cfg field /tmp/e.rs && ./e
Hello World A
% rustc --cfg inner --cfg field /tmp/e.rs && ./e
/tmp/e.rs:19:23: 19:24 error: unresolved enum variant, struct or const `C`
/tmp/e.rs:19         #[cfg(field)] C(_) => "C",
                                   ^
error: aborting due to previous error
% 

[pnkfelix]

@alexcrichton I thought it was by design that when you import an enum type, you were supposed to automatically get its variants without having to import them explicitly?

[alexcrichton]

I was unaware of such a design! If so, then this seems like just a bug, if not though, we may have some other issues...

[sfackler]

Variants definitely do not auto-import in my experience.

[pnkfelix]

admittedly, I do not recall where I got the impression that enum import worked this way. (and on a test case i just hacked up, none of the variants get auto-imported into a sibling module. so perhaps this is an artifact of some interaction between the parent and child modules.)

But etiher way, we should resolve what the appropriate semantics are here. I have no problem

[emberian]

This is scary.

[pnkfelix]

@alexcrichton is right. (I still don't know how I got the impression I had, but then again, clearly someone working on resolve had the same impression I guess...)

P-backcompat-lang, 1.0. (And I need to change the test better illustrate that the matches of A and B are matching variants, not binding.)