Macro input future proofing

[emberian]

Implements RFC 550 (rust-lang/rfcs#550)

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[sfackler]

This case doesn't need to exist, does it?

[nikomatsakis]

OK, reviewed. Algorithm seems close but not quite right, particularly around adjacent non-terminals (which can't be soundly permitted without a FIRST set) and the repeaters.

[nikomatsakis]

@cmr I'm ok with => in the follow sets of types and expressions. @alexcrichton points out that for expressions we kind of are stuck with it anyway because of _ if foo => in patterns. Also, given that we want to add type ascription, an expression can always end in a type, so it makes sets for the follow sets of the two to be the same.

[nikomatsakis]

Sorry, that was too strong. And we don't need type ascription, we already have expr as Type. So really just follow(expr) <= follow(type) (I think), and since => is in follow(expr), should be present for type as well.

[SimonSapin]

I use this macro a lot:

macro_rules! is_match {
    ($value:expr, $($pattern:pat)|+) => {
        match $value {
            $($pattern)|+ => true,
            _ => false
        }
    }
}

But it now gives error: $pattern:patis followed by|, which is not allowed for pat fragments. Why is this specific pair not allowed? Is there a work-around?

[SimonSapin]

For what it’s worth, upgrading rust-url to the latest nightly is blocked on this.

[emberian]

@SimonSapin that combination is disallowed to provide for extending patterns with |-alternation in the future. Right now, | in "pattern" is handled entirely by match.

The only tokens allowed to follow pat at the moment are =>, ,, and =.

[SimonSapin]

@cmr, so there is no way to write a macro the accepts multiple patterns with the same syntax as match? I don’t care if it’s with $($pattern:pat)|+ or with a single $pattern:pat, but making it impossible is a pretty bad regression.

[alexcrichton]

@SimonSapin thanks for pointing this out! We were deliberately quite conservative in choosing the "follow sets" for this RFC as we can always expand them over time! For patterns specifically, I think we must allow | in the follow set because we could never extend the grammar of a pattern to include a | token (it would cause many ambiguities today).

If you'd like, you could open a PR modifying the relevant code to have a bit more discussion (someone should validate my thinking)

[SimonSapin]

Ok, @huonw suggested a work around that I’m happy with:

#[macro_export]
macro_rules! matches {
    ($expression: expr, $($pattern:tt)+) => {
        _tt_as_expr_hack! {
            match $expression {
                $($pattern)+ => true,
                _ => false
            }
        }
    }
}


/// Work around "error: unexpected token: `an interpolated tt`", whatever that means.
#[macro_export]
macro_rules! _tt_as_expr_hack {
    ($value:expr) => ($value)
}

tt allows sneaking another match arm in, which isn’t great, but better than picking a random ASCII character for the delimiter.

matches!("foo", "bar" | "baz" => 42 > 9000, "fuzz");