We currently need a scope/environment walk to get the |this|-environment's callee. I think it would be nicer to add a separate JSOP_THISENVCALLEE op with an uint8 numHops operand so we don't need to figure this out at runtime.

Looking at GetSuperEnvFunction, I'm not reminded of any complications. I support this idea.

We now emit JSOP_CALLEE or JSOP_ENVCALLEE (a new op) to load the callee. JSOP_SUPERFUN and JSOP_SUPERBASE no longer have to walk the scope/environment chain.

This worked out nicely. It also improves our Ion coverage a bit I think: we supported JSOP_SUPERBASE only when super was used directly in a derived class method. Now we also handle the case when it's in an arrow function.

So one problem is that EmitterScope::enterEval does not call checkEnvironmentChainLength and we can fail the numHops <= UINT8_MAX assertion. Possible ways to fix this are: (1) Call checkEnvironmentChainLength in enterEval and enterGlobal, for consistency with the other enter* methods. (2) Check numHops in BytecodeEmitter::emitThisEnvironmentCallee. I think I want to try (1) first. There might be some (crazy) website relying on huge eval depth but I think it's the right fix.

Or maybe (2) is the simpler/safer fix for now. arai, what do you think?

I'll just go with (2) for now and file a follow-up bug to explore (1) :)

I agree that (2) is the right option here. I don't think there can be many hops between super call/access and constructor, in ordinary code, so throwing an error for it should be reasonable. and also, solving the (1) case separately should be better.

Pushed by jdemooij@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5555defbbd01 Simplify JSOP_SUPERFUN and JSOP_SUPERBASE by factoring out the callee lookup. r=arai