Support non-qualified imports of macros and imports which happen after the macro is used

[ModProg]

Now that item macros are working again (#521) it is visible, that importing them does not:

use std::experiments::make_function;

pub fn main() {
    hi()
}

make_function!( hi => { println("hello") } );

One should also not forget the order shouldn't matter:

pub fn main() {
    hi()
}

make_function!( hi => { println("hello") } );

use std::experiments::make_function;

And to make matters worse, probably a macro could resolve to an import that imports a different macro.

The issue is probably this loop: https://github.com/rune-rs/rune/blob/ebfb91ee930d52767748eb1c2cde34b2e13748f6/crates/rune/src/indexing/index.rs#L404

This should probably whenever it finds a macro it cannot resove push it back to be processed after the other imports.

In rust the use in macro-expansion works:

macro_rules! use_you {
    () => {
        use hello::you;
    };
}

fn main() {
    you::println!("Hello, world!");

    use_you!();
}

mod hello {
    pub mod you {
        pub use std::println;
    }
}

[udoprog]

These are two know limitations:

• Macro imports must use ::std, or fully qualified paths. This is because local modules could otherwise affect resolution, which is only something that can happen at a later compilation stage. Currently we only have one pass of indexing and macro expansion, and one pass of compilation.
• Macro imports must happen before the macro is used.

This is simply an effect of how macros are integrated into the system, for now. It can clearly be improved but we don't have the necessary subsystems to do so! This could possibly be fixed by further deferring macro expansion to happen after at least one round of complete indexing - then uses which happen after the macro would be seen.

A technical limitation to make this kind of deferment happen is that specific points of the AST can't be very easily referenced for later processing, we just currently rely only mutable access to the AST as we walk over it.

I've added this bug report as linked in #27.

[ModProg]

• Macro imports must use ::std, or fully qualified paths.

oh sorry, that I missed.

[udoprog]

Not your fault. The macro system is still work in progress, and I'm not sure this is expressed elsewhere except in maybe the issue which implemented it.

[udoprog]

I might've been a bit hasty, after re-reading the code it seems like we can actually handle use processing during indexing (leading to #526).

What we currently do not handle is module expansion though, but one out of two problems is pretty neat anyways. Thanks for pointing me in the right direction!