[DRAFT] Allow customisation of metaprogramming via scalac flags

[japgolly]

Fixes #12038

Disclaimer: the names used are just drafts and still need some good bikeshedding, and some parts of this need some tidying up. This PR is currently for feedback.

[bishabosha]

Hi @japgolly, do you plan to work any more on this?, we are trying to clean up open PR

[japgolly]

@bishabosha @nicolasstucki Conditionally, yes!

Let me give some context: After raising this I thought I might be able to implement this as a compiler plugin instead. I made some progress in https://github.com/japgolly/ctenv but ended up stopping because it just seemed way too hard because a plugin can't intercept the calls at the ideal time/phase. Instead it became a huge hackfest where I retrospectively tried to patch generated ASTs and ultimately it's just not feasible. You can partially get it working a simple cases but it's super brittle and impossible to have it work reliably.

OTOH, this implementation here was super easy. It would be great to pick this up again, and I'm conditionally willing to update and maintain the PR to get it merged. The reason I say conditionally is that I don't wont to get more invested and spend lots of effort only for this to end up in the bin so I think the first step would be to discover whether or not this would really be accepted. I love to get the concept approved in some form before working further on the implementation.

I think @nicolasstucki (or was it @bishabosha?) had some concerns about the impact on tasty. So if code is compiled with scalac flags specifying a=1 and then is used downstream with a scalac flags specifying a=2, what should happen? Should a=2 take effect and result in different code when using the tasty generated with a=1? I think this isn't a problem for tasty itself because we're talking about inlined bodies which aren't expanded until concrete use anyway. In cases where one wouldn't want a=2 to override a=1 I could extend the syntax to make it specifiable. Are there any other concerns that would need to be addressed before approving the spirit of this feature? Or maybe put another way, what would it take to get this or a similar feature approved?

[japgolly]

Oh, other potential concerns:

• should the env/flags themselves be stored in tasty?
• if a isn't overridden downstream, should the a=1 still be available via tasty? What about diamond problems?

It seems to me that the compile-time env should only persist for the current compilation phase, and not be transitive. I don't foresee any problems with that and it would be a much simpler design, but would love to hear any counter points of view.

[nicolasstucki]

This kind of logic should be in the reflection interface first. If it is, this method can be implemented in any external library.

[neko-kai]

Lack of -Xmacro-settings[1] is currently one of the blockers for porting Izumi libraries, since we heavy rely on them to add build info for self-reporting to libraries and applications.

Regarding reproducibilty: Reading from environment is a side effect; side-effecting macros cannot be and aren't meant to be reproducible - instead they are used for their side effects, which by design may differ in each build. I hope that's not a deal breaker for Tasty recompilation – before I assumed that applied macros would be expanded to their resulting tasty trees and wouldn't have to be re-executed for recompilation – requiring re-execution would impose a lack of side effects on macros which would be a heavy restriction to work with.

[1] - I'm biased towards keeping the existing name and API from Scala 2, rather than renaming to -E

[rssh]

I moved the @japgolly test case from here into #14234 (merged in), so this issue can be closed as implemented.