Rust macros don't really understand the types involved.

If you have a derive macro for

    #[derive(MyTrait)]
    struct Foo {
        bar: Bar,
        baz: Baz,
    }

then your macro can see that it references Bar and Baz, but it can't know anything about how those types are defined. Usually, the way to get around it is to define some trait on both Bar and Baz, which your Foo struct depends on, but that still only gives you access to that information at runtime, not when evaluating your macro.

Another case would be something like

    #[my_macro]
    fn do_stuff() -> Bar {
        let x = foo();
        x.bar()
    }

Your macro would be able to see that you call the functions foo() and Something::bar(), but it wouldn't have the context to know the type of x.

And even if you did have the context to be able to see the scope, you probably still aren't going to reimplement rustc's type inference rules just for your one macro.

Scala (for example) is different: any AST node is tagged with its corresponding type that you can just ask for, along with any context to expand on that (what fields does it have? does it implement this supertype? are there any relevant implicit conversions in scope?). There are both up- and downsides to that (personally, I do quite like the locality that Rust macros enforce, for example), but Rust macros are unquestionably weaker.

Rust macros are a mutant foreign language.

A much much better system would be one that lets you write vanilla Rust code to manipulate either the token stream or the parsed AST.

It doesn't have access to the type system, for example. It just sees it's input as what you typed in the code. It wouldn't be able to see through aliases.