Bulk memory reduces active segments to sequences of *.init that are executed
before the start function is called. This implies that an error here is to be
reported as a RuntimeError, as an error in the start function would. The latest
spec tests for bulk-memory check this, so we're required to update as well.
Differential Revision: https://phabricator.services.mozilla.com/D54598
--HG--
extra : moz-landing-system : lando
When fuzzing, return an error instead of crashing in PrincipalInfoToPrincipal() for some error cases.
Differential Revision: https://phabricator.services.mozilla.com/D54215
--HG--
extra : moz-landing-system : lando
Whereas:
- desktop tests don't make this check;
- the check for directory existence has been troublesome and almost never useful;
- bug classification of this condition has been troublesome;
- if a startup crash actually did occur before crashreporter init, there would still be an indication in logcat and possibly a tombstone, and the "No test summary found" check would definitely be triggered;
Let's stop checking for minidumps directory creation.
Differential Revision: https://phabricator.services.mozilla.com/D54755
--HG--
extra : moz-landing-system : lando
Make the $PYTHON3 build var point to a full virtualenv bootstrapped with
the same libraries as the $PYTHON Python 2 build var. This allows us to
upgrade build tasks from $PYTHON to $PYTHON3.
This patch adds some debug logging and documentation to the Python
2 virtualenv so that it is easier to diagnose issues that may arise
from running two different Python interpreters in re-entrant
multiprocess routines.
Differential Revision: https://phabricator.services.mozilla.com/D50819
--HG--
extra : moz-landing-system : lando
Homebrew on OS X will change Python's sys.executable to a custom value
which messes with mach's virtualenv handling code. Override Homebrew's
changes with the correct sys.executable value.
Differential Revision: https://phabricator.services.mozilla.com/D54602
--HG--
extra : moz-landing-system : lando
Build a full sysroot by downloading the `wasi-sdk` repo, which has `llvm-project` and `wasi-libc` as submodules. `wasi-sdk` builds a `clang` in a unique configuration (with `wasm32-wasi` as a default target) and uses that `clang` to build the rest of the pieces for the wasm sysroot.
In principle it should be possible to build the sysroot using our in-house automation-built `clang`, but I kept running into strange, hard-to-diagnose issues when I attempted that. If someone else is able to straighten out all the compilation issues, we could replace this script and stop pulling in `wasi-sdk` entirely, which would result in a build that takes much less time overall. Until then, this will have to do to unblock the rest of the wasm sandboxing work.
Differential Revision: https://phabricator.services.mozilla.com/D54560
--HG--
extra : moz-landing-system : lando
An error means that javadoc is being copied to the incorrect folder as the {project} variable is incorrectly formatted
Differential Revision: https://phabricator.services.mozilla.com/D54731
--HG--
extra : moz-landing-system : lando
In GLES the default precision for ints is only 16 bits in the fragment shader.
Differential Revision: https://phabricator.services.mozilla.com/D54000
--HG--
extra : moz-landing-system : lando
The 'multi-brush' shader will have to dynamically switch between different brushes. In order to support that without needing the sum of all brush varying locations, allow aliasing a number of generic slots.
This patch makes the assumption that one a vec2 and a vec4 cost the same amount of varying register space, which is suggested by the glsl specification about shader locations. If it is not the case we can add more granularity to the varying slots which are all vec4 at the moment. This also assumes that an unused varying is always optimized out.
Differential Revision: https://phabricator.services.mozilla.com/D53726
--HG--
extra : moz-landing-system : lando
This is an experiment with only image and solid to see what the infrastructure can be like.
If it works out I'll extend the it with more brush types. More work will be needed to get text rendering in there as well.
The multi-brush shader includes all brushes that it potentially needs suport for. Which brushes actually get compiled in is then specified via WR_FEATURE defines.
Since brushes can't have the same names for their entry points, they specify the function to use via a macros (WR_BRUSH_VS_FUNCTION and WR_BRUSH_FS_FUNCTION).
Differential Revision: https://phabricator.services.mozilla.com/D53725
--HG--
extra : moz-landing-system : lando
This will allow the upcoming super-brush shader to select its behavior at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D53724
--HG--
extra : moz-landing-system : lando
This chanes the shader parsing code to only inject #included shader sources once (the first time) if they are included multiple times.
This will allow some extra flexibility needed by the multi-brush shader.
Differential Revision: https://phabricator.services.mozilla.com/D53651
--HG--
extra : moz-landing-system : lando
This adds a tp5n-multiproc output directory which contains postprocessed
versions of the tp5n set. They are processed to take iframes with relative
URLs and output absolute URLs with domains similar to their original
domains. This will help us better simulate a real-world case for Fission,
which will split processes based on the ETLD+1 of the domain.
Differential Revision: https://phabricator.services.mozilla.com/D53065
--HG--
extra : moz-landing-system : lando
This only affects console api calls where one of the
argument is an empty string. Since we don't quote
string arguments for those, it was difficult to spot
an empty string there.
Jest test are added, as well as a mochitest for the
console to make sure that we don't have unwanted
side effects (for evaluation results, object with
empty string properties, ...)
Differential Revision: https://phabricator.services.mozilla.com/D54687
--HG--
extra : moz-landing-system : lando
