You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I traced this and the issue is triggered by the fact that from the viewpoint of macropy.core.macros.Block.detect_macro, curry doesn't only update the existing nodes in in_tree.body, but replaces the body with something else, when it wraps the original tree in a with dyn.let(...):.
If the macros are invoked in the same with, this new tree is never seen by show_expanded - it gets just the updated nodes of the original in_tree.body.
Using nested with blocks (and keeping in mind the from inside out expansion order), the expansion works as expected - show_expanded sees the with dyn.let(...): inserted by curry.
It seems this can be fixed very simply - PR to follow.
The text was updated successfully, but these errors were encountered:
These expand differently:
I traced this and the issue is triggered by the fact that from the viewpoint of
macropy.core.macros.Block.detect_macro
,curry
doesn't only update the existing nodes inin_tree.body
, but replaces the body with something else, when it wraps the original tree in awith dyn.let(...):
.If the macros are invoked in the same
with
, this new tree is never seen byshow_expanded
- it gets just the updated nodes of the originalin_tree.body
.Using nested
with
blocks (and keeping in mind the from inside out expansion order), the expansion works as expected -show_expanded
sees thewith dyn.let(...):
inserted bycurry
.It seems this can be fixed very simply - PR to follow.
The text was updated successfully, but these errors were encountered: