Disallow macro-in-macro

[Simn]

This PR disallows calling a macro while in macro context. We do this by replacing macro calls with throw "macro-in-macro". This means that you get a proper eval exception with stacktraces and can also debug it.

Macro-in-macro has been a long standing problem for various reasons. Combined with the fact that I think nobody actually wants to use this as a feature and only does so accidentally, I propose that we remove it entirely for Haxe 4.

As for the benefits of this change, it

• removes the last reason why inlining could still be canceled,
• eliminates a cryptic cause of the compiler cache not working for certain modules and
• probably addresses a leak due to the captured ctx that was used for typing the macro at macro run-time.

Please note that it doesn't complain about a macro-in-macro being typed. The error only triggers if it ends up actually being called. This is an important distinction because it means we don't need additional #if macro fencing.

[ncannasse]

Good for me, although I think we should be able to properly support macro-in-macro by creating a second macro context (which would use same interp because of cache), the only problem being infinite loops for which we should limit the depth and then fallback to your solution of a runtime error.

[Simn]

I experimented with this and I don't think it's a good idea. Properly supporting macro-in-macro would mean that we expand macros while typing the macro context. That would mean a huge shift in semantics because suddenly all your macros get called twice if you have the macro in the same class as the call.

[ncannasse]

Well, they actually do get calls N times where N is the depth level we allow (macro-in-macro-in-macro-in-...). Another possibility would be to forbid calling macros in the module you're currently macro'ing - the way your current patch does it.

…

On Tue, Oct 2, 2018 at 11:51 AM Simon Krajewski ***@***.***> wrote: I experimented with this and I don't think it's a good idea. Properly supporting macro-in-macro would mean that we expand macros while *typing* the macro context. That would mean a huge shift in semantics because suddenly all your macros get called twice if you have the macro in the same class as the call. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#7496 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwMUL4-7sHXvClv6IPyvMnPkNJpUPks5ugzcRgaJpZM4XA3aW> .

[Simn]

Well, they actually do get calls N times where N is the depth level we allow

That would only be true if we keep creating macro contexts, which doesn't sound like a good idea in the first place.

But what I really ask myself in all this is: Why? Does this bother you only on a technical level or do you see legitimate use-cases for macro-in-macro? I just don't think the complexity is worth it.

[ncannasse]

There are two kind of macros : API macros that helps with building specific content (CastleDB, Heaps resources, SQL macros, etc.) and more "generic" programming macros that can help to better express some high level concepts. While the "specific" macros are only used from the main context I can see the "generic" macros being themselves used in macros. But I agree it's not a big show stopper for me or my team atm.

…

On Tue, Oct 2, 2018 at 12:03 PM Simon Krajewski ***@***.***> wrote: Well, they actually do get calls N times where N is the depth level we allow That would only be true if we keep creating macro contexts, which doesn't sound like a good idea in the first place. But what I really ask myself in all this is: Why? Does this bother you only on a technical level or do you see legitimate use-cases for macro-in-macro? I just don't think the complexity is worth it. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#7496 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA-bwCZ5DYruOT9Du5uO6lBMiKFQ4e2oks5ugznmgaJpZM4XA3aW> .

[Simn]

I'll merge this for now. If we decide to support macro-in-macro in the future we can discuss this further.