Foreach in sketch

[graydon]

This is a preliminary implementation of for ... in ... { ...} using a transitionary keyword foreach. Codesize seems to be a little bit down (10% or less non-opt) and otherwise it seems quite trivial to rewrite lambda-based loops to use it. Once we've rewritten the codebase away from lambda-based for we can retarget that word at the same production, snapshot, rewrite the keywords in one go, and expire foreach.

Feedback welcome. It's a desugaring-based approach which is arguably something we should have been doing for other constructs before. I apologize both for the laziness associated with doing it this way and with any sense that I'm bending rules I put in place previously concerning "never doing desugarings". I put the expansion in expand.rs and would be amenable to the argument that the code there needs better factoring / more helpers / to move to a submodule or helper function. It does seem to work at this point, though, and I gather we'd like to get the shift done relatively quickly.

[brson]

Desugaring is definitely the right approach here - it's awesome how low-impact this is. I imagine the error messages could get troublesome though.

With the desugaring strategy how to we make for work for both Iterator and Iterable? I'm imagining we'll just have to implement one in terms of the other.

[huonw]

Fwiw, there's a pile of AST building methods in ext/build.rs, and so the mk_* functions are probably unnecessary (and most of the direct construction of ast structs/enums).

[graydon]

@brson to work with Iterator and Iterable I imagine it'll suffice to take the reference to the result of a call like let _i = &mut to_iter(<iter_expr>) or perhaps .iter(), assuming we implement it on Iterator to just return self. I wasn't sure we wanted to do that yet, but it should be backwards compatible to enhance for that in the future.

[bluss]

The bug #7597 is tracking Iterable. Compiler bug prevents it at the moment.