emscripten-core / emscripten

Emscripten: An LLVM-to-WebAssembly Compiler
Other
25.69k stars 3.29k forks source link

closure compiler issue #6219

Closed wothke closed 6 years ago

wothke commented 6 years ago

I recently installed emscripten 1.37.29 (Win10Pro 64-bit) and I am now re-testing (& updating the make scripts of) my various old projects (which I had last tested successfully using emscripten 1.35.0).

One of my projects: https://github.com/wothke/uade-2.13 suddenly no longer compiles when using "closure=1".

With the older emscripten I had used "closure=1" without any problems, as can be seen on the
page: http://www.wothke.ch/webuade/ - which uses the respective old output.

Update; The source of the problem seem to be 2 global/trivial utility functions that I am providing via --pre-js .. and which are then used from lib code that I am adding via --js-library. (if I remember correctly I had used the extra --pre-js since I had not succeeded to directly define them within the --js-library - which I would have preferred)

It seems that that new closure compiler for some reason eliminates the two utility functions..

wothke commented 6 years ago

PS: after changing the content of the --pre-js file from:

startsWith= function (a, str) {.. }

to

function startsWith(a, str) {.. }

"closure=1" now also works with the new emscripten version...

kripken commented 6 years ago

Is there anything else with the name startsWith in those files? Another possible reason is that function startsWith applies in the entire scope, I think, unlike the assignment which is only after it.

If it's neither of those, it could be a bug in closure, it would be good to file it for them.

wothke commented 6 years ago

I just ran a fulltext search (using "SearchMyFiles" app - I am aware that the built-in Win10 search isn't worth shit..): The only places that "startWith" shows up in are the definitions of my 2 functions and their use in the pre.js and the callback.js file that I am including via --pre-js and --js-library. I think the former case can be ruled out.

It might be something to do with the latter - eventhough I would have guessed that the --pre-js file gets included right at the start of the module and should be visible to the --js-library stuff that comes later? In any case the code did work as long as "closure=1" wasn't used, so it does not seem to be a general JavaScript scopeing issue.. but then I am no expert on that ;-)

For all practical purposes I can well live with the above workaround. All 9 emus again run nicely and the size of the WASM output is down to 50%.. nice :-) http://www.wothke.ch/blasterWASM/

kripken commented 6 years ago

Yes, a pre-js will be before js library code.

Ok, I guess there's nothing left to do here. The issue might be worth bringing up with upstream closure if someone wants.

Running that link, now I have my background music for today ;)