Could TypingTransformer be more efficient?

[retronym]

In https://github.com/scala/scala/compare/2.13.x...retronym:faster/transformer-faster?expand=1, I demonstrate an idea I've had for a while to try to optimize our compiler "middle end".

• Replace the atOwner idiom in Transformers with pushOwner / popOwner. Subclasses can customise these and stack context into ArrayBuffer. This will be allocation free, as opposed to the closures that currently need to be allocated to pass to atOwner.
• Avoid the indirection through the bridges implied by api.Transformer to reduce the Java stack depth during transforms (making stack traces easier to read, cheaper to collect in profiles, and maybe more inlinable)

This might also lead to a way for us to have a lighter weight localTyper, without a full Typer/Context combo.

• Verify correctness of the patch (partest --pos works so far)
• Benchmark the change for compile speed and allocation rate
• Look at the stack traces of the transform for user friendliness

The followup idea is the try to tag each Type and Tree subclass with an Int and replace our pattern matches on these with a @switch match.

[retronym]

That branch seems to perform identically to the baseline.

[info] HotScalacBenchmark.compile                          a8c43dc                    false  2.13.0-pre-0f70451-SNAPSHOT    scalap  sample  630  663.717 ± 1.664  ms/op
[info] HotScalacBenchmark.compile                          a8c43dc                    false  2.13.0-pre-6850e7f-SNAPSHOT    scalap  sample  624  664.023 ± 1.819  ms/op

-prof gc suggests an 0.5% reduction in gc.alloc.rate.norm

[retronym]

Some more WIP which uses a mutable Context: retronym/scala#76

[dwijnand]

Looks like this doesn't really provide benefits? But I'll keep it open for future experiments.