improve Triton assembly macros

[jan-ferdinand]

• allow creating labels like {label}_tail, fixing Concatenated labels in TASM #220
• simplify declaration (of internal relevance only)

It should be possible to make label building more general but I find it difficult to do¹ so without metavariable expressions, which are currently unstable.

Footnotes

1. probably more a testament to my macro-writing skill than anything else ↩

[Sword-Smith]

Very nice. Looking forward to this :)

[jan-ferdinand]

Experimenting and reading up on the matter, I can't seem to achieve the behavior I want using declarative macros. In particular, I would like to allow building labels like {expr}ident but disallow {expr} ident – the whitespace in between makes all the difference.¹ Since declarative macros operate on token trees, whitespace is not preserved. As a consequence, detecting whether some token is part of a label becomes quite difficult. While it might work for label declarations, uniquely terminated by a colon, a call followed by a series of tokens can be ambiguous. Does call {my_list}push{my_item} describe a call to {my_list} followed by instruction push with {my_item}, or is the intended call target {my_list}push{my_item}?

A workaround² is to fully declare the desired label within the expression:

{format!("{my_label}_inner")}: push 0 return
…
call {format!("{my_label}_inner")}

Note also that I can't easily mimic the internals of the format! macro, which is used in the workaround: internally, format! uses the format_args! macro, which is a compiler built-in.

The proper solution is to go full proc-macro, which is something that I want to do anyway. It just means that the fix for #220 is a bit further away than I thought it to be.

Footnotes

1. Successfully matching {expr} ident as a label causes issues like {my_instruction} my_label: or call {my_label} halt being erroneously matched and fused. ↩

2. ugly, but works today ↩

[Sword-Smith]

Too bad that this is not possible. Thanks for looking into it though!

[jan-ferdinand]

I do plan to add the functionality. By closing this branch, I didn't want to communicate that #220 is off the table. It's just that the approach tried here does not work. ☺️