Resolution Design about gccrs HOT 7 CLOSED

BTW, to perform type resolution correctly, I think the order should be:

name resolution -> macro expansion -> type resolution

But it's fine if we implement each step parallelly.

from gccrs.

Name resolution and macro expansion need to be interleaved for the following to work:

macro_rules! a {
    () => {
        macro_rules! b {
            () => {}
        }
    }
}

a!();
b!();

#![feature(decl_macro)]

macro a($b:ident) {
    macro $b() {}
}

b!();
a!(b);

from gccrs.

@philberty Yes, the pass, I think this term implies everything, extensible and can be disabled for certain purposes. We need a tiny framework for these passes (and options for disabling and debug), maybe we can do it after resolution an expansion.

from gccrs.

Yes this is a really good idea.

The way i envision things is many "Passes" and a pass i mean a Class using the ASTVisitor pattern and we have a state machine to work the work in there. We can even flesh out later with warning passes such as DeadCode recounting the names as it goes and when things go out of scope we iterate all nodes with a refcount == 0 as dead code.

I recently Added a simple pass rust-scan.cc which we will need in subsequent passes to know about global declarations as functions can be declared after they are used etc.

from gccrs.

@bjorn3 Ah yes, thanks for mention, I'll keep it.

from gccrs.

I have now pushed a big pr for the new resolution frameworks. For macros we need a toplevel name resolution pass and then we can do macro expansion. I will make some documentation on how the IDs are working to help.

from gccrs.

I will add documentation to the WIKI on how the resolution is working to be able to close this issue.

from gccrs.