Emscripten: closure compiler error "only supported for ECMASCRIPT6 mode"

[claudeha]

code is quite involved, depending on several libraries. but this changed recently, it worked with emsdk incoming from 2019-01-10 or so (can't be more precise right now due to hardware failure), but broke with a fresh one today.

https://mathr.co.uk/empd/#build-cleanroom build scripts here, it fails at line 26 of the 3rd script

emcc -I../../..//pure-data/src -I../../..//libpd_wrapper -O3 -o pdtest.html pdtest.c --closure 1 -s USE_SDL=2 --preload-file test.pd -L../../..//libs -lpd
/home/empd/src/emsdk/emscripten/incoming/third_party/closure-compiler/node-externs/domain.js:67: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler for more information.
 * @param {function(...[*])} callback
                       ^

/home/empd/src/emsdk/emscripten/incoming/third_party/closure-compiler/node-externs/domain.js:68: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler for more information.
 * @return {function(...[*])}
                        ^

/home/empd/src/emsdk/emscripten/incoming/third_party/closure-compiler/node-externs/domain.js:73: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler for more information.
 * @param {function(...[*])} callback
                       ^

/home/empd/src/emsdk/emscripten/incoming/third_party/closure-compiler/node-externs/domain.js:74: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler for more information.
 * @return {function(...[*])}
                        ^

/tmp/emscripten_temp_OPXcim/pdtest.bc.o.js.pp.js.mem.js.jso.js.jso.js.jso.js.jso.js:1: ERROR - This language feature is only supported for ECMASCRIPT6 mode or better: block-scoped function declaration.
...
1 error(s), 4 warning(s)
shared:ERROR: closure compiler failed (rc: 1)
make: *** [Makefile:12: pdtest.html] Error 1

see attachment for full error (too big for body).
make.log

[kripken]

Are you using a custom version of closure compiler, and not what emscripten bundles?

To debug this, you can build with EMCC_DEBUG=2 in the env, and the temp files will be saved, so you can read the closure input.

[bsokol]

Have the same issue from version 1.38.25. I am using internal closure compiler from EMSDK.

.../AppData/Local/Temp/tmpfqz0nq.cl.js:5838: ERROR - This language feature is only supported for ECMASCRIPT6 mode or better: block-scoped function declaration.
            function b(c, t) {
            ^

1 error(s), 0 warning(s)
shared:ERROR: closure compiler failed (rc: 1)
..../HTML5/Game/makefile:21: recipe for target 'Build/libs/app.js' failed
mingw32-make.exe: *** [Build/libs/app.js] Error 1

[bsokol]

@kripken it looks like there is a new CC version in 1.38.25 SDK:

emscripten\1.38.24\third_party\closure-compiler\compiler.jar - 7,11 MB (7 456 280 bytes)
emscripten\1.38.25\third_party\closure-compiler\compiler.jar - 9,90 MB (10 385 566 bytes)

[kripken]

I see, thanks. Is it possible the JS causing the issue is added in your project? Then our update of CC may make it show new errors on existing code. Building with -s IGNORE_CLOSURE_COMPILER_ERRORS=1 may work around it.

Does changing ECMASCRIPT5 to 6 in tools/shared.py fix things for you? I wonder if we shouldn't just do that.

[bsokol]

I will check both options tomorrow and let you know!

[bsokol]

@kripken is there any way to preventing files like /emscripten_temp/tmpsebzo2.cl.js from delete?
EMCC_DEBUG=2 works great for files like: app.bc.o.js.mem.js or emcc-2-original.js
but all tmp*.cl.js files are immediately deleted during building :/

[bsokol]

Changing ECMASCRIPT5 to ECMASCRIPT6 in shared.py generates 90 warnings and 2 errors like these:

AppData/Local/Temp/tmpjedaht.cl.js:2487: WARNING - dangerous use of the global this object
          this['toWireType'] = genericPointerToWireType;
          ^^^^

AppData/Local/Temp/tmpjedaht.cl.js:3051: WARNING - dangerous use of the global this object
                  throw new TypeError('Cannot convert "' + _embind_repr(value) + '" to ' + this.name);
                                                                                           ^^^^

AppData/Local/Temp/tmpjedaht.cl.js:3105: WARNING - dangerous use of the global this object
                  throw new TypeError('Cannot convert "' + _embind_repr(value) + '" to ' + this.name);
                                                                                           ^^^^

AppData/Local/Temp/tmpjedaht.cl.js:5813: ERROR - variable process is undeclared
      var t = process['hrtime']();
              ^^^^^^^

AppData/Local/Temp/tmpjedaht.cl.js:5905: ERROR - variable Buffer is undeclared
      buf = Buffer.from(s, 'base64');
            ^^^^^^

2 error(s), 90 warning(s)

[kripken]

all tmp*.cl.js files are immediately deleted during building :/

Yeah, I noticed that too - looks like a bug. Annoying, I agree. Not sure how easy it would be to fix.

About the ECMASCRIPT6 warnings and errors, those sound like things we need to fix anyhow, as supporting ES6 is important.

[juj]

.../AppData/Local/Temp/tmpfqz0nq.cl.js:5838: ERROR - This language feature is only supported for ECMASCRIPT6 mode or better: block-scoped function declaration. function b(c, t) { ^

This is a WONTFIX regression in Closure compiler. They no longer want to support functions defined inside block scopes when targeting EcmaScript 5. The issue is https://github.com/google/closure-compiler/issues/3189.

The fix is to move such functions out from being inside blocks, to the very top of the function, or outside the function to global scope.

[juj]

AppData/Local/Temp/tmpjedaht.cl.js:5813: ERROR - variable process is undeclared
      var t = process['hrtime']();
              ^^^^^^^

AppData/Local/Temp/tmpjedaht.cl.js:5905: ERROR - variable Buffer is undeclared
      buf = Buffer.from(s, 'base64');
            ^^^^^^

These are fixed in #7947.

[forresthopkinsa]

So what's the solution for emscripten users then?

[juj]

So what's the solution for emscripten users then?

The fix is to move such functions out from being inside blocks, to the very top of the function, or outside the function to global scope.

[forresthopkinsa]

Clearly I have not expressed my question well enough for you.

So if I'm converting C code to JS (in this case, ffmpeg.js), and emsc is then following that generated code with a CC run, at what point am I expected to change the order of the generated JS functions? That doesn't really make sense.

Or are you talking about the C code? That doesn't really make sense to me either.

It sounds like you're suggesting that this is the result of user-added JS, but I don't believe that to be the case.

Anyhow, changing from ECMASCRIPT5 to ECMASCRIPT6 fixed it for me. If the problem is in ffmpeg.js' javascript, then I guess that's their problem.

[ssikyou]

Same error here building ffmpeg even using incoming SDK, set IGNORE_CLOSURE_COMPILER_ERRORS and ECMASCRIPT6 does not help, any ideas?

[kripken]

I think I may understand the confusion here - if so, #8170 should fix this. Please test if you can.

I think @juj thought the error is coming from user-provided JS code, and his suggestion is how to refactor that code to comply with current closure compiler rules. But I think the errors @forresthopkinsa and others have seen are from emscripten JS code - it turns out we didn't have full test coverage of closure on all our JS library. That PR adds that testing + fixes.

[ssikyou]

Actually, I found a bug in pre.js, changing ECMASCRIPT5 to 6 does fix for me now. Also checked with #8170, it fixes building without changing to ECMASCRIPT6.

[kripken]

Great, thanks @ssikyou!