For loops should not be desugared

[LemmingAvalanche]

Using a constant in an enum with the same name as another constant from another enum in the std module - namely Option in this case - causes an error in a (seemingly) unrelated for-loop. "Mangling" the name of this constant - say from None to NoneN - makes the code compile.

Compiler used:

rustc 0.11.0-pre-nightly (eda75bcf42ad99e3e4c99585d39705fccac606ee 2014-07-03 16:56:51 +0000)

Code:

fn main() {
    enum Test { None }
    for i in range(0, 10u) {
        println!("{}", i)
    }
}

Output:

$ rustc debug_2.rs
debug_2.rs:3:5: 6:2 error: mismatched types: expected `core::option::Option<uint>` but found `main::Test` (expected enum core::option::Option but found enum main::Test)
debug_2.rs:3     for i in range(0, 10u) {
debug_2.rs:4         println!("{}", i)
debug_2.rs:5     }
debug_2.rs:6 }
error: aborting due to previous error

[pcwalton]

Yeah, we have to fix the for iteration for 1.0. Nominating.

[emberian]

A simple fix is expanding to ::std::option::None, but a more comprehensive fix would involve "import capturing" that I've discussed with @jbclements, @pcwalton and @brson

[pnkfelix]

Assigning P-backcompat-lang, 1.0 milestone, under the assumption that we will at least make the situation much much less fragile by adopting some solution, perhaps along the lines that @cmr outlined in the previous comment.

[jbclements]

Just to be clear, it also requires hygiene for these names. Actually, this probably wouldn't be too hard--though you'd almost certainly wind up merging resolution and expansion. :)

[pcwalton]

Updated title with what is (IMO) the best near-term solution. This solution may improve compile times as well by adding less macro expansion and making the trans code simpler.