Expand macros in patterns

[kmcallister]

First commit is an unrelated fix for a test suite warning I introduced last week.

[emberian]

cc @paulstansifer

[huonw]

This should probably go through an RFC.

[lilyball]

@huonw It seems like an RFC-worthy change, but is anyone actually against this? I thought we just didn't support it before because nobody had put in the effort, not because it's actually controversial.

I'm definitely in favor 👍

[lilyball]

Looks like one of the commits here references #6830, so we actually have a year-old issue specifically asking for this. And it was filed by @huonw.

[kmcallister]

Unfortunately this program ICEs my branch:

#![feature(macro_rules)]

macro_rules! foo ( () => (()) )

fn main() {
    match () {
        x @ foo!() => (),
    }
}

with

task 'rustc' failed at 'attempted to analyze unexpanded pattern', /home/keegan/proj/rust/rust/src/libsyntax/ast_util.rs:667

I'll think tomorrow about how to fix this, if nobody beats me to it.

[huonw]

Is it expanding patterns recursively? (E.g. does Some(foo!()) ICE too?)

@kballard: an RFC is not just "does this have widespread support", it is also a semi-formal documentation of expected semantics and a place to address any potential issues (e.g. hygiene and potential grammar ambiguities would warrant mentions, although I can't think of any problems with those two, off the top of my head). That issue was filed long before the RFC process was even a glint in Rust's eye.

[paulstansifer]

This is cool!

@huonw: I also don't think that either of those things are going to be a problem (regarding hygiene, pattern variables are probably just another item on the long list of things that don't get to participate in hygiene until someone implements it for them), and I can't think of any other probable issue.

[brson]

Agree this should be an RFC. I'm very afraid that our macros are becoming a house of cards due to ad-hoc features being added before the existing features even work reliably.

[kmcallister]

Sounds good; I'll submit an RFC.

@brson: I agree that Rust macros have some rough edges, and I expect some early-adopter pain from using them so heavily in the HTML parser I'm writing. That's basically in-scope for the Servo project. Macros are feature-gated and it's fine if I have to rewrite them in the future, as long as I can still do basically the same things.

It seems that every large systems project contains some build-time code generators, scary C macros, and/or C++ metaprogramming weirdness. When you have exacting requirements at runtime, it's extremely useful to do complicated things at compile time. Or these projects just tolerate a lot of boilerplate. Macros are the main reason my tokenizer is 900 lines instead of 6,000 like the others I've seen. And the concise form is much closer to what's in the spec. I need pattern macros to realize similar gains in the other major parser component (the tree builder).

Sorry about the mini-rant ­— I know we all agree macros are useful. I just want to emphasize that powerful macros are an exciting and important feature for me, right up there with lifetime checking.

[kmcallister]

This is rust-lang/rfcs#85.

[kmcallister]

That last commit fixes the ICE I described above.

[huonw]

s/pos/position/

[huonw]

I'd like to see some tests for hygiene working (e.g. that let foo!() = 1; x + 1 fails but let bar!(x) = 1; x = 1 doesn't, for foo expanding to x and bar to its argument), and also the incomplete parse error (can add to src/test/compile-fail/macro-incomplete-parse.rs).

[kmcallister]

Rebased, and comments addressed.

[huonw]

r=me after squashing some commits (or not, doesn't really matter, r=me in either case).

[kmcallister]

I'll squash those.

[anasazi]

r=huonw