get super accessors logic out of mixin phase, into superaccessors phase

[SethTisue]

eventually this will help permit the elimination of implementation classes. for now, just trying to shuffle the code around without changing what bytecode is generated. (we can check this by diffing the bytecode)

we'll need to synthesize trees for the super accessor methods and add entries for those trees to the info. the stuff we synthesize will look different than the stuff that mixin currently synthesizes, because the implementation class won't exist yet, so instead of generating calls to the i.c., we'll generate something that will eventually be compiled into the right invokestatic calls.

it should be easy to find the relevant code in mixin (and elsewhere), because there’s a “super” or “superaccessor” flag, I guess, that I can just grep for.

Dotty already does it this way, so we might look at what they did. we might also raid Dotty (e.g. scala/scala3#756) for test cases.

[SethTisue]

old notes on possible plans of attack:

• write some tests that break when you comment out the relevant code, and then work on getting them passing. "explorations, especially if you turn them into tests, is super useful"
  • perhaps think about doing some code generation where you can specify what kind of test you want

troubleshooting/testing techniques:

• usually, just looking at the trees
• you can use ASM to inspect generated bytecode and verify desired properties e.g. “making sure all fields emitted are private”, assertions like that.
  • Dotty has per-phase invariant checks that you can turn on. scalac has -Ycheck, Dotty has something much better. -Ycheck is “sort of hopeless”. we don’t use -Ycheck, usually. but maybe we should be adding invariant checks to -Ycheck.

[SethTisue]

detailed notes on how compilation of super accessors currently works: https://gist.github.com/SethTisue/400a5acf6678f6550f0f

[SethTisue]

(I didn't end up working on this. not sure what Adriaan ended up doing)