diag: macro diagnostic shows incorrect line number

[benstt]

The following snippet fails to compile, and the diagnostic references an incorrect line number for the error:

fn main() {
    macro wrapper() {
        println("I forgot to invoke this macro!");
    }

    wrapper!();
}

The error I get:

/usr/local/bin/alumina-boot --cfg threading --sysroot /usr/local/share/alumina --debug --output build/debug/macro_diag.c \
        macro_diag::main=src/main.alu
error: unexpanded macro (hint: append `!` to invoke it)
  --> src/main.alu:6:5

In this case, src/main:6:5 is not where the actual error is, but in src/main:3:9. This can be confusing, especially when other macros call each other.

fn main() {
    macro wrapper() {
        println("I forgot to invoke this macro!");
    }

    macro wrapper_wrapper() {
        wrapper!()
    }

    macro yet_another_wrapper() {
        wrapper_wrapper!()
    }

    yet_another_wrapper!();
}

produces:

/usr/local/bin/alumina-boot --cfg threading --sysroot /usr/local/share/alumina --debug --output build/debug/macro_diag.c \
        macro_diag::main=src/main.alu
error: unexpanded macro (hint: append `!` to invoke it)
  --> src/main.alu:14:5

It would be nice to either:

• show the root line number causing the problem
• provide context around the error (i.e., displaying a snippet of the code)
• providing the macro name where the failure is
• all of the above?

Compilation Info

Revision: 8a621ba34ccf041bf963b46ad25f9756d43650b8

8a621ba3 (HEAD -> master, origin/master, origin/HEAD) feat(stdlib): Test framework improvements (#114)

[tibordp]

Woo, a first user of Alumina that's not me :100:

Macros being opaque for the purpose of diagnostics is somewhat intentional, as this allows programs to e.g. define custom macros that report the span of the call site instead of the macro itself (which would not be terribly useful), see for example: https://play.alumina-lang.net/?code=929c1ff2e347fad9

I think it would be useful to provide this additional context in the form of "stack trace" like it is done during monomorphization, but currently once AST is constructed, each AST node has just one (or none) source span attached.

I think diagnostics in general leaves a lot to be desired - I'll leave this issue open, but probably it'll be a while before I get to it.

[benstt]

That makes sense, thank you for the example.

By the way, really liking the language so far -- it combines all of the features I like from different PLs I've tried. Nice work!