For loops should not be desugared #15392
Comments
|
Yeah, we have to fix the |
|
A simple fix is expanding to |
|
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. |
|
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
changed the title
|
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. |
This makes edge cases in which the `Iterator` trait was not in scope
and/or `Option` or its variants were not in scope work properly.
This breaks code that looks like:
struct MyStruct { ... }
impl MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
for x in MyStruct { ... } { ... }
Change ad-hoc `next` methods like the above to implementations of the
`Iterator` trait. For example:
impl Iterator<int> for MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
Closes rust-lang#15392.
[breaking-change]
librustc: Stop desugaring `for` expressions and translate them directly.
This makes edge cases in which the `Iterator` trait was not in scope
and/or `Option` or its variants were not in scope work properly.
This breaks code that looks like:
struct MyStruct { ... }
impl MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
for x in MyStruct { ... } { ... }
Change ad-hoc `next` methods like the above to implementations of the
`Iterator` trait. For example:
impl Iterator<int> for MyStruct {
fn next(&mut self) -> Option<int> { ... }
}
Closes #15392.
[breaking-change]
Use the warning color when rust-analyzer is stopped If the rust-analyzer server isn't running, we can't do much. Treat this state as a warning color, so it's more obvious.
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:
Code:
Output:
The text was updated successfully, but these errors were encountered: