|
|
Previously delayed macro expansions (the sole purpose of macroExpandAll)
were triggered by `typedArgs`. Probably I wanted to save CPU cycles on
not checking whether we have pending macro expansions on every iteration
of typecheck.
However this optimization is uncalled for, because the check just entails
reading a var, therefore benefits of the current approach are negliible,
whereas the robustness hit is tangible.
After delayed macro expansion mechanism became more robust, it exposed
a bug, well-hidden before. If one first delays a macro and then finds out
that the expandee is erroneous, subsequent `macroExpandAll` will crash,
because it expects a macro runtime attachment to be present. Previously
the erroneous code path never got triggered, because the macro expansion
never commenced. Luckily the fix was easy.
|
