Synthesising members that need to be visible to other code currently being typechecked is a very delicate procedure, e.g. our implemenation of case classes in the Namer is pretty tough to understand. The hard part is that you want to base the logic of the macro on Types, rather than just syntax, but to get types you might trigger typechecking of code that will observe a scope before your macro has added/amended it. This could manifest as a fatal cyclic error, or as a failure to typecheck code that expects the synthetic members to be available.
How can we providing API/infrastructure support to macro authors who try to walk this tightrope? This is a core question, but one that requires a serious investment of research.
This question is orthoganal to the question of what API should be used to interrogate or synthesize trees or types, or the whether macros can be executed in the IntelliJ presentation compiler (which are both Hard Problems™️ in and of themselves!)
One small part of this research I’d like to see is a review of Java’s annotation processors (http://docs.oracle.com/javase/9/docs/api/javax/annotation/processing/package-summary.html#package_description). What can we learn from the design? What restrictions are imposed that would be too strict for our uses? How (if at all) do Java annotation processors integrate into IntelliJ’s presentation compiler?