Allow certain ES6 constructs in internal JS code

[sbc100]

With this change we allow these features by default. If a user
explicitly opts into older browser support we trigger the running
of closure compiler with --language_out ES5 --compilation_level WHITESPACE_ONLY.

For most users this will be a code size win, but otherwise a no-op.

For users who need older browser support they will now have their
output run though closure by default. If they want to take a care
of the transpilaion process themselves rather than have emscripten
to it auto-magically they can run with --closure=0.

When we auto-magically run closure to do transpilation we generate
a warning. This warning can be suppressed by add --closure=1 to
explicitly opt in, or --closure=0 to explicitly opt out.

This change in does not actually include any usage of these features
and so don't include the code size benefits. Those will be part of
followup PRs: #15764 #15765 #15758

Fixes: #11984

[kripken]

I had some comments about using closure here (speed etc.), but I don't see them here. Was that in another PR? Is this the right one to discuss closure in?

[sbc100]

I had some comments about using closure here (speed etc.), but I don't see them here. Was that in another PR? Is this the right one to discuss closure in?

Your question about performace was in the followup PR: #15764 (review), but this is the right issue in which to discuss since this is PR which will start enabling it by default for those that target older browsers.

I will do some measurements.

[sbc100]

I measured the performance of emcc with -sINCLUDE_FULL_LIBRARY which is think represents the about the worst case. In this mode emcc will generate a raw JS output file which is around 1Mb in size.

Without measured the performance of using emcc as linker in 3 modes. The base case of emcc -s INCLUDE_FULL_LIBRARY hello.o (where hello.o is the pre-compiled object form of the hello world program. The full closure case (with --closure=1) and the transpile-only case (with -sMIN_CHROME_VERSION=10). I ran each version 3 times.

• base case: 672ms 648ms 668ms.
• full closure: 4.177s 4.297s 4.270s (~7x slowdown over base)
• transpile only: 1.828s 1.725s 1.806s (~3x slowdown over base)

So, in general I think is safe to say that transpiling is less have have the cost of full closure. These are also the absolute worse case.. its hard to imagine real project using INCLUDE_FULL_LIBRARY or otherwise including a 1Mb of JS.

[sbc100]

I ran the same test without INCLUDE_FULL_LIBRARY to get results for a more typical JS output size (125k):

• base case: 559ms 524ms 555ms.
• full closure: 2.523s 2.485s 2.486s (~5x slowdown over base)
• transpile only: 1.064s 1.055s 1.057s (~2x slowdown over base)

So I think we have some evidence that supporting older browsers will slow down the links by between 2 and 3 times.

[kripken]

Thanks for the measurements! Very useful info.

I think an extra ~1 second during link is acceptable if supporting legacy browsers is a rare case, since we get significant benefits in return thanks to this (smaller code size in general).

I wish we had good data for how rare this is in practice among our users. Hard to get a representative sample, of course, so I don't have any good ideas here. But hopefully not many support legacy browsers in practice, and this is off by default. Also these requirements are higher than the requirements for wasm, in fact, so this would only just affect wasm2js users. Btw, do you know how many of our tests would get slower here? I think almost none, since we hardly test LEGACY_VM_SUPPORT or MIN_*_VERSION.

lgtm aside from tests.

[sbc100]

Added more testing including -O2

[sbc100]

I investigated the transpiration of let and const and arrow functions and they looks like they to the obvious and minimal thing.