support 'ast::Expression::Name' for macros

[jwerle]

This would allow for the use of ast::Expression::Name types in a macro expression. One use case I can imagine is a @format() macro to support things like:

int a = 1;
int b = 2;
@format("let sum = {1} + {1} + {2} + {2} + {3}", a, b, 123);

An advanced case could be something similar to rust's std::fmt::Display trait where the @format() macro could make a call to a display() function based on tokens in the format string, similar to format!() in rust

[aep]

could you add a test please?

[jwerle]

@aep absolutely! I am writing it now :upside_down_face:

[jwerle]

@aep okay test added!

[jwerle]

and here we go! https://github.com/zzmodules/format

[aep]

That's a good start. However it doesn't really replace printf, which is often broken on embedded systems. What's would be convenient here is the macro knowing which type the passed in expressing has, but macros can't do that yet. I'm not even sure how rust does it, as the macro pass happens before the type resolver because it might change types of other stuff.

The display() function is very wrong. You're creating a temporary string and returning a memory reference that is invalid after return. UBSAN should have thrown an error

[aep]

A possible remedy to lacking types is using c type dispatch, but that is a very new fearure that won't work on all c compilers.

Instead I think macro invocation needs to be moved into the expand phase where expression types are available. But then the expand phase also needs to be improved to understand types of local variables. It's a long way to go before this becomes good

[jwerle]

Yes it was very hard and hacky to make work with how macros currently work at the moment. I do not like the display function at all neither, but I wanted to get something wrong or right for feedback. I don't think what I was trying to achieve will be possible as I tried to integrate this module into a project, and it didn't work as expected.

Probably will scrap until macros improve