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.