Currently, when Maki analyzes a macro invocation, it always wraps the contents of the emitted macro's body in a return statement.
However, this is not correct for macros which do not expand to expressions, or expand to void expressions.
There are 2 ways to fix this:
Only wrap a macro's body in a return statement if the macro is a function-like macro that expands to a non-void expression. This would save some work for downstream macro-to-C translation tools since they could just use this body to transform the macro to a function definition, but the downside is that we'd have to annotate each invocation with the macro body, instead of only the macro definition, because we can only infer type signatures from macro invocations.
Change the Body field to just contain the raw text of the original macro definition. This would be a far more flexible approach, but puts the onus on downstream translation tools to correctly transform the body into an appropriate target language construct (e.g., to a C function or variable definition).
I'm currently in favor of 2 but am open to other ideas.
Currently, when Maki analyzes a macro invocation, it always wraps the contents of the emitted macro's body in a
returnstatement. However, this is not correct for macros which do not expand to expressions, or expand tovoidexpressions. There are 2 ways to fix this:returnstatement if the macro is a function-like macro that expands to a non-void expression. This would save some work for downstream macro-to-C translation tools since they could just use this body to transform the macro to a function definition, but the downside is that we'd have to annotate each invocation with the macro body, instead of only the macro definition, because we can only infer type signatures from macro invocations.Bodyfield to just contain the raw text of the original macro definition. This would be a far more flexible approach, but puts the onus on downstream translation tools to correctly transform the body into an appropriate target language construct (e.g., to a C function or variable definition).I'm currently in favor of 2 but am open to other ideas.
Related to #5.