Allow macros to expand to multiple items

[bstrie]

https://gist.github.com/4480389

The macro here is expanding to only the first statement in its definition. According to pauls, this is because "the mac system is currently only able to expand a macro to a single item", and that this should be fixed. Make it so that a macro instead expands to all the statements in its definition.

[paulstansifer]

Fixing this mainly will entail editing fold.rs so that one item can fold to multiple items. The odd thing is that there are a number of places in the AST where exactly one item is accepted; I haven't investigated what's up with them.

[brendanzab]

This is sorely missed. Here is a use case where I'd love to have it (more on the way):

pub trait Cast {
    static fn from<T:CastTo<self>>(x: T) -> self;
}

pub trait CastTo<T> {
    fn cast(&self) -> T;
}

macro_rules ! impl_casts {
    {$from:ty -> $($to:ty),+} => {
        pub impl $from: Cast {
            #[inline(always)] static fn from<T:CastTo<$from>>(x: T) -> $from { x.cast() }
        }

        $(
            pub impl $from: CastTo<$to> {
                #[inline(always)] fn cast(&self) -> $to { (*self) as $to }
            }
        )+
    }
}

impl_casts! { u8    -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { u16   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { u32   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { u64   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { uint  -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { i8    -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { i16   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { i32   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { i64   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { int   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { f32   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { f64   -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }
impl_casts! { float -> u8, u16, u32, u64, uint, i8, i16, i32, i64, int, f32, f64, float }

The alternative (as you can imagine) is frighteningly verbose.

[jbclements]

agreed that expanding into multiple items would be very important/useful. Another alternative would be to have an explicit "item-sequence" AST node, that gets flattened at some point during compilation.

[sanxiyn]

Jeaye suggests using mod to group multiple items as a workaround. Isn't mod exactly "item-sequence" AST node @jbclements wanted?

[bstrie]

Nominating this for a milestone, as per bjz's plea.

[dobkeratops]

i was looking for this feature too whilst writing something to auto generate a struct alongside some sort of serialization assist. (initially I tried to declare a struct plus a default 'to_str()' that formated it in a JSON-esque manner).

[jedestep]

I've been looking into this; @sanxiyn 's suggestion seems to be the simplest way to get this done. Still work left to do but generally the approach is to have MRAny hold a vector of items instead of just a single one and propagate this change appropriately.

The goofy hack alternative would be to literally inject a module into the macro, __macro__<macroname> or something, and pub use it.

[nejucomo]

Hello. I've just started exploring @jedestep 's comment by changing MRAny to MRAny(@[@AnyMacro]). I figure that definition will be "easiest" to get working, then later I can see if it makes more sense to have @[AnyMacro] or ~ pointers instead.

Right now I'm waiting for make check to expose all the type mismatches. I'm new to rust, and I've only spent about 20 minutes reading over ast.rs and ext/base.rs so we'll see how this goes. ;-)

[nejucomo]

I haven't had time yet to explore the MRAny redefinition. I thought I'd point out a relevant pull request, #9673, which disallows multi-item expansions explicitly, instead of implicitly dropping after the first.

[alexcrichton]

I believe that the purpose of #9673 is to stop silently ignoring extra items, but it'd still be awesome to be able to expand to multiple items (meaning that the safeguard in #9673 would be removed).