I'm trying to fix TestJVMCompiler#test_loop, which is failing
because compiled macros are automatically wrapped in an "isolated"
ScopedBody i.e. ScopedBody#parent is always nil on a macro
ScopedBody (refer to add_compiled_macro in
lib/jvm/types/intrinsics.rb).
As a result, the compiled loop macro has no visibility of the
variable `a` declared outside of the macro (in the MethodDeclaration
scope) and so the type of `a` cannot be inferred within the loop
macro. And even if it could, it would not be valid (what's the
result of adding a value to a variable that doesn't exist within a
scope?).
I tried "fixing" this by adding something like this to
add_compiled_macro fixes test_loop:
body.static_scope.parent = call.scope.static_scope
It breaks a couple of the Java source tests. I have a feeling these
may be either bugs in the Java source backend, or perhaps I just
need to give it a bit more attention.
What *does* concern me is that it breaks test_macro_hygene, because
the breakage here raises some questions about the semantics of
macros. If I'm understanding the code correctly, the "isolated"
ScopedBody has been added to prevent namespace conflicts at the
points in the source where the macro is compiled -- we don't
actually *want* a "true" ScopedBody here (even add_compiled_macro
says so!), it's just a convenience to prevent macros borking things
in strange and wonderful ways.
Any thoughts on how we might address this properly? At a glance,
rewriting variable names in macros might suffice (e.g. `x` in a
macro might be written to `x$1` or something to that effect at macro
compile time) but I'm not sure that this is a particularly graceful
way to do things.
Cheers,
Tom