Item macros do neither support import lines nor inner attributes

[Kimundi]

I'm trying to switch a few of the libstd macros from generated module to multi item macros, and I've run in a few issues:

Import lines are not supported:

#[feature(macro_rules)];

macro_rules! items(
    () => (
        use std::option::Option;
    )
)

items!()

multi_item_macro_bugs.rs:5:31: 5:32 error: view items are not allowed here
multi_item_macro_bugs.rs:5         use std::option::Option;
                                                          ^

Inner attributes are not supported:

#[feature(macro_rules)];

macro_rules! items(
    () => (
        #[feature(globs)];
    )
)

items!()

multi_item_macro_bugs.rs:5:25: 5:26 error: macro expansion ignores token `;` and any following
multi_item_macro_bugs.rs:5         #[feature(globs)];
                                                    ^

I'm not sure if those two are intentional limitations or not, but if they are, then not all use cases for macros-expanding-to-generated-modules can be replaced with item macros. (See std::num::uint_macros for a big example)

[huonw]

Allowing either seems like it would introduce some points that need to be carefully considered, e.g. for uses

macro_rules! conflict {
     () => {
        use bar::foo; 
        fn inner() { foo::func() }
    }
}

mod foo { pub fn func() {} } // A

mod bar {
    pub mod foo { pub fn func() {} } // B
}

fn before() {
    foo::func();
}

conflict!()

fn after() {
    foo::func();
}

I see 3 possibilities if the above were legal:

1. the use is scoped to the macro itself so before and after both call A, but inner calls B
2. the use only rebinds foo in after (i.e. before calls A, and inner and after call B)
3. the use is as if it were written at the top of the module, i.e. doesn't rebind foo at all (and so all three foo::func() call A)

All three have their peculiarities; I think 1 may make pub use impossible in a macro (without some custom re-exporting magic), 2 is weird (and I think disallowing this is one of the reasons that we currently only allow view items at the top of modules now), and 3 gives you spooky action-at-a-distance where an import magically appears (and can rebind other imports) throughout the whole file from some macro halfway down it (and it means that a macro that is importing something specifically can have it's symbol overwritten... I guess this may be addressed by hygiene and is point 1 anyway).

Similarly for top-level attributes, one can have, e.g. a #[cfg] being attached to a module from a macro invocation buried in the middle of the file.

[huonw]

No change.

[thehydroimpulse]

/cc me

[steveklabnik]

both of these now compile just fine.