Upstream merge #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Support deleting Fetch.xhrs * Define _fetch_free_xhrs * define emscripten_fetch_free_xhrs as just a call into JS * Added a missed comment * Change splice to delete, rename _fetch_free_xhrs to _fetch_free * renaming * renaming part 2
* Implement wake all semantics when emscripten_futex_wake(addr, INT_MAX); is called * Add test for emscripten_futex_wake with INT_MAX to wake all
The emsdk ships libc and a few other libs, and we used those, instead of building libc here - so we missed a regression that was only caught later on releases CI. I'm surprised we didn't hit more problems earlier, actually... The regression was that we added a constructor priority in pthreads, and apparently that keeps it not just alive but separate from other ctors, which adds an extra function to the number. I refactored that code to make it clear what we do in the pthreads and non-pthreads cases, and made us only use the priority when using pthreads.
Documents the -flto and WASM_OBJECT_FILES=0 options, which are not identical as the latter also affects system libraries. Also document that --llvm-lto 1 is needed to actually run lto opts (otherwise we pass --lto-O0 to wasm-ld). Add a test for -flto and WASM_OBJECT_FILES=0 emitting bitcode files as expected.
See WebAssembly/binaryen#2226 This will break CI until emscripten releases has new builds for the emscripten+binaryen combo.
Sadly the last PR had a small error for fastcomp + asyncify, so we can't land the bysyncify=>asyncify double roll without this.
Turns out at least some of the duplicate logging we have is because if a python web request hander doesn't return any headers, it just calls it again. Odd that this doesn't recurse infinitely... anyhow, just send some empty headers for the logging code to avoid that. Also fix the logging in python3, where urllib is structured differently.
…%d (#8859) This way instead of function calls being like aClass.someMethod = function(arg0) {...} they will now be like aClass.someMethod = function(argNameFromIDL) {...} For the example IDL: interface aClass{ void someMethod(boolean argNameFromIDL); } This makes debugging much easier, as function args can have descriptive names.
Asyncify wasm error handling leads to unreachables being thrown. This PR maps those errors into calls to abort(), which ensures the runtime is properly shut down if they occur. In particular, no more code will be run, which could previously be confusing while debugging. Background: Asyncify is designed as a standalone binaryen pass - it knows nothing about emscripten. You can run it on arbitrary wasm. So it uses the universal unreachable error mechanism. (We could add an "emscripten" mode to it there, but I preferred to keep the emscripten-specific details here in emscripten.)
…hrome (#9002) Due to https://bugs.chromium.org/p/v8/issues/detail?id=9075 we disabled pthreads tests on chrome. The fix has reached beta now, so after upgrading to beta we can re-enable those tests. I upgraded firefox to nightly recently, but @tlively mentioned that beta was new enough (for passive segments stuff), and looks like everything else works there too, so downgrading to beta (to avoid noise from nightly which might be unstable). Overall beta seems like a reasonable compromise between new features and stability.
We no longer have the version number in the path, and we do have fastcomp or upstream. Fixes #8927
) This removes emcc_args usage from the benchmarks - it has no effect on benchmark output, I verified. (In theory the benchmarks may have existing bugs in them were their makefiles don't have a -Ox flag in them, and they depended on us passing the flag through emcc_args - but that would have been a bug all along, anyhow.)
That led to errors in browser.test_chunked_synchronous_xhr as an object there could not be postMessage'd - the printing commands forwarded their inputs to the main thread, and abort() was sending them an object. Remove the extra quotation marks there too - it's just extra code size for no reason. This may not fix all random errors in that test, but at least when a random error occurs it will be able to print the error message now.
* Add v8 to CI. This is used in a few tests already, like the new simd ones. * Simplify testing code to use node instead of spidermonkey or v8, where we used those because we assumed node didn't have wasm yet. Fix various small bugs that follow. * Show Enlarging memory arrays, this is not fast warning on wasm2js, because like in asm.js, growth there means a big copy of the entire memory. * In wasm synchronous compilation mode, handle not just the spidermonkey error text for a bad memory size but also the v8 text. Also throw the error properly. * Remove a monotonic timer test that was v8 specific and has not been run for many years - it seems like the old test depended on the d8 timer being monotonic, and it seems like that's changed (maybe it behaves more like Date.now()), as this isn't a stable interface we just shouldn't test it.
…aybe due to the version update, maybe due to using headless) (#9009)
This still has an async step, but a deterministic one - we run code in the very next browser event loop, and nothing else is async here, so all we do is basically skip over other code (a possible postRun) in this iteration of the event loop. Fixes #8939
This allows glob patterns like `asan.test_a*` to be used on ASan and LSan tests.
The test is marked @flaky which runs it up to 3 times to try to avoid a random error. But we never shut down the server, so the second and later runs would just hit an error on trying to create a server on the same port. (Of course not shutting down the server was bad for other reasons too!) Hopefully this will decrease dramatically the number of random failures on this test, but it won't eliminate them entirely.
…ecently the frequency of all 3 has increased a bunch. Could be the firefox update. (#9008)
- Create update scripts for each of these libraries. - Update from llvm source tree at tag llvmorg-8.0.0. - Re-apply 3 local change in libcxx.
I went through all the tests marked as no_wasm_backend. A fair bit now work! Those are enabled here. I clarified some comments on the non-working ones, and filed issues for the small number that seem like they should pass, or at least are in need of looking into, and linked them. Some tiny test fixes were needed in some cases. I also fixed a tiny bug in llvm_opt for the wasm backend, which it turns out is only used in the one place in one test.
This moves us from Xenial (16.04) to Bionic (18.04), the current LTS. This seems useful by itself as there are probably more users there. Fixes #9044 by using the system sphinx (avoiding the the pip version of sphinx which has broken). The system version is 1.6.7, which is a downgrade from 1.7.8.
I believe the issue is the newline difference on that platform. This should fix current broken rolls on this repo, e.g. https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket.appspot.com/8907222997982694992/+/steps/Emscripten_testsuite__upstream__other_/0/stdout
…#9045) This change avoids the binaryen addition of the flags causing tests to break, as we assert on surprising flags in emscripten.py. It sets the value of that param to a pessimistic 1 (assume main does read its params). This does nothing for now. After this lands, the binaryen PR [1] can land, and then a PR that adds the actual optimization and testing here. [1] WebAssembly/binaryen#2247
…nting implicit convertibility to non-noexcept qualified function pointers (#9027) Fixes the problems discussed here: #9005 The problem stems from newer compiler versions complaining about implicitly converting noexcept function pointers to function pointers without noexcept annotations. std::vector::size() is one such function.
…e that out. this will unbreak the roll (#9058)
The html5 setImmediate code should not assume there is always addEventListener defined.
… (+ a test for the fixed docs) (#9041)
Even if no parameter is provided, to avoid confusion (exiting without anything logged can be puzzling). Also the code is shorter this way!
This lets the wasm backend path not emit code to set up argc/argv if main doesn't need them. It also avoids that code bringing in some string and stack allocation support (metadce improvements are from the latter). This reduces --closure 1 -O3 size of hello world by almost 10%.
new Buffer() is now deprecated:
[DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.
If emscripten drops NodeJS < 6, just Buffer.alloc(BUFSIZE) is okay, but it's missing on NodeJS < 6.
…avoid random flakes there. (#9066)
…9047) This replaces Module['readBinary'] with readBinary etc., that is, moves them from Module to be just normal JS variables. This change allows better JS minification: the names read, readAsync etc. can be minified now, and even better if the variables are not used then they can be removed entirely. On hello world this saves 4% of JS size in -O3 --closure 1 with the wasm backend. This is an internal API change. However, it's possible some users depend on it, so I added a mention in the changelog, and in builds with ASSERTIONS an error message is shown if the old APIs are used. Note that read is also renamed to read_ (since "read" is an API call in the SpiderMonkey shell).
gcc and clang do not expand symlinks or the such when -no-canonical-prefixes is specified; emcc should not do so either.
This was deprecated around when Emterpreter-Async came around, which was a long time ago. Also we now have a new Asyncify in the upstream backend, so it's a good time to remove the old one. This will also make work on the new one easier (e.g. it had a whitelist already, and supporting two variants would be annoying). People that still need Asyncify can use an older version (1.38.40), but upgrading to upstream and the new Asyncify is recommended.
Removed unused functions/vars, terminated unterminated statements, * Changed const to var * Change "this.err" to "var err" * tempDoublePtr should only be available in !MODULARIZE
This new setting lets the user define which Module arguments will be provided at runtime. By default we assume, as always, that the user may provide any such API. With this new setting, the compiler can be told at compile time that only some of those values may be arriving. That allows it to not emit code for all the options that are not. This starts to optimize using that option, but only does a little work so far. Specifically, Module['arguments'], Module['thisProgram'], Module['quit'] are all optimized, that is, they are no longer placed on Module, and they are not read from Module unless the user expects them to be provided at runtime. (Again, that is the default, so no existing code should break.) On hello world this saves 2.5%, but again, this option lets us optimize a lot more later. In principle, I think this option is key to letting us remove the bulk of unnecessary code from our minimal JS, in fact.
…on object (#9051) Enable `class_<T>.constructor` to accept both `std::function` and function object types. This is useful in scenarios where you want a stateful function object for purposes such as gathering statistics or performing other generic functionality on each call.
…elevant for upstream (#9082)
This is a part of #9054 : I've noticed that EM_ASM accepts not only ints, but unsigned chars and some other types as well (e.g. in this test failure EM_ASM gets a uint8_t, which turns out to be unsigned char).
* Fix #9068: get rid of malformed newlines in emcc errors on Windows This fixes a patch applied to acorn.js for quoting error-causing text in parse errors (acornjs/acorn#793). Previously it splitted binary data on \n to get lines, which was inconsistent with the rest of the parser and caused excess \r in the error message on Windows. Now it uses the same regex as the rest of acorn.js (e.g. getLineInfo used by error reporting). * Fix #9057 by fixing by #9068
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thank you for submitting a pull request!
If this is your first PR, make sure to add yourself to AUTHORS.