Use ScriptThingVariant to represent closed-over-bindings and inner-functions
for lazy functions. Inline the body of BaseScript::CreateLazy as well so we
can use EmitScriptThingsVector to init the gcthings. We take care to keep
setting the enclosingScript link.
Differential Revision: https://phabricator.services.mozilla.com/D74036
Initialize the FunctionBox fields from parameters instead of a
FunctionCreationData instance, and allow creating the JSFunction directly
from the FunctionBox. This allows us to remove most fields from the
FunctionCreationData type.
Note that we still use a default instance of FunctionCreationData to
correctly fill in CompilationInfo::funcData list. Future work will address
that when we unify with ScriptStencil.
Differential Revision: https://phabricator.services.mozilla.com/D73883
The only caveat here is that gfxVars are not atomic, but multiple threads can
query DWM status. To solve this, changes to the var are mirrored into an atomic
and that is read instead.
DWM status changes are indicated by Windows via a window message. We use that
window message to cause the update to propagate
Differential Revision: https://phabricator.services.mozilla.com/D73743
Currently, There are multiple places that call the Win32 APIs for DWM status.
Once Win32k lockdown is enabled, this API will be unavailable and will need
to be remoted. This new function will be made to work in both parent and
content processes, and therefore all DWM queries must be directed to it.
Also, some minor cleanup because... Why not?
Differential Revision: https://phabricator.services.mozilla.com/D73742
This follows D73070. Remainings are Init(), DestroyFrom(), and several functions that are not used by nsIFrame methods, which will be also merged in separate patch(s).
Differential Revision: https://phabricator.services.mozilla.com/D74041
Unbox here seems a bit wrong, because usually the value isn't used afterwards.
(Interestingly enough we actually do use the value with TruncateDoubleToUInt32)
I doubt this will ever be a performance problem however.
GuardType doesn't just unlock bitwise arithmetic but also other stubs.
Depends on D73975
Differential Revision: https://phabricator.services.mozilla.com/D73976
`LLoadTypedArrayElementHole` used to need to a safepoint for a vm-call (bug 737783),
but this vm-call was later removed in bug 829896.
Differential Revision: https://phabricator.services.mozilla.com/D72643
The next part needs `ToBigIntPolicy` when storing BigInts into a typed array.
`MToBigInt` is currently only used as part of `ToBigIntPolicy`, therefore we
have to bailout for effectful operations, like `ToBigInt(object)`. Only strings
and booleans can be handled without a bailout.
Differential Revision: https://phabricator.services.mozilla.com/D72641
There are too few registers available on x86, therefore `LLoadTypedArrayElementHoleBigInt`
is reusing the ValueOperand's type register, similar to `CacheIRCompiler::emitLoadTypedElementResult`.
`LLoadUnboxedBigInt` and `LLoadTypedArrayElementHoleBigInt` are both using an OOL vm-call
if the result BigInt can't be allocated inline, similar to `CodeGenerator::visitInt64ToBigInt`.
Differential Revision: https://phabricator.services.mozilla.com/D72640
THis should continue allowing users to zoom out in RDM mode, or any time that
we are respecting the meta-viewport tag. It's only when we don't respect the
meta-viewport tag that we disable zooming out past initial zoom.
Differential Revision: https://phabricator.services.mozilla.com/D73461
These two tests need to be updated to be aware of the new dotAll flag.
If we ever have to turn off the new engine, this patch should also be temporarily reverted.
Depends on D73118
Differential Revision: https://phabricator.services.mozilla.com/D73119
If a regular expression is too big, the assembler may fail with RegExpError::kTooLarge. When it does so, we want to throw an error: "regexp too big".
Until the most recent reimport of irregexp, we were actually reporting an OOM in these cases, because `CompilationResult::code` was default-constructed as an UndefinedValue and we took the "OOM in GetCode" path. Now `CompilationResult::code` is a Handle, so we crash if we try to access the value.
Making the situation slightly more complicated is the fact that we still have a macroassembler live, which means that we can't GC, which means that we can't report an error. The old code used an AutoSuppressGC for this (https://searchfox.org/mozilla-central/source/js/src/irregexp/RegExpEngine.cpp#1703), but that seems like an extremely blunt instrument.
Instead, I've refactored `CompilePattern` to call a separate `Assemble` function. This means that we clean up the macroassembler before we call `JS_ReportErrorASCII`. The new function is a straight copy-paste of the old code, except for error handling and `.` to `->` conversions for the values being passed by reference. Note that the order of checks has changed after calling `compiler->Assemble(...)`: now we check `result.Succeeded()` before examining `result.code`.
We also change the shared labels in SMRegExpMacroAssembler to be NonAssertingLabels. This suppresses assertions in the Label destructor that they are not used without being bound. The assertion is already suppressed for OOM (https://searchfox.org/mozilla-central/source/js/src/jit/Label.h#82-86), which is why we did not trigger it previously.
Differential Revision: https://phabricator.services.mozilla.com/D73758
There are a few changes here:
1. The code that used to be in wrapBody was moved to RegExpCompiler::PreprocessRegExp.
2. The `code` field in RegExpCompileData used to be a bare Object, and is now a Handle<Object>. (This makes named captures way easier to implement, because it lets us to allocate GC things while parsing a regexp without angering the hazard analysis.) I also took this opportunity to remove some dead code in the shim implementation of Handle.
3. Upstream V8 made a change to simplify the interface with the interpreter. Previously, the caller of IrregexpInterpreter::MatchForCallFromRuntime was responsible for allocating enough memory to hold both the capture results and the scratch registers. Now, the interpreter has the same interface as the compiler: the caller passes in a buffer large enough to hold the capture results, and the memory for the scratch registers is allocated internally. This requires a few small additions to the shim (IsInRange plus new methods on JSRegExp and SmallVector).
Depends on D73117
Differential Revision: https://phabricator.services.mozilla.com/D73118
This is as good a time as any to pull in some recent upstream changes (many of which I wrote). This patch was auto-generated using import-irregexp.py. The necessary changes to the shim code are in the next patch.
Depends on D73116
Differential Revision: https://phabricator.services.mozilla.com/D73117
Interpreted bytecode is ~3-5 times slower than compiled code, but ~5-10 times smaller. In general it seems like this is a good trade-off for the first few iterations, but for particularly long input strings this can cause a significant slowdown before we tier up. V8 eagerly tiers up to compiled code when the input string is 1000+ characters long. Following their lead on this fixes a significant regression in sunspider-regexp-dna.
Differential Revision: https://phabricator.services.mozilla.com/D73116
The engine supports parsing named captures, but we don't have the code in place to expose the captured groups. Until we do, this code will make sure that we get a syntax error when parsing them.
Differential Revision: https://phabricator.services.mozilla.com/D73115
If a look-behind back-reference succeeds, we have to subtract the length of the capture from the current position (so that the current position points to the beginning of the capture). We don't have the length in a register, so we have to read it from the capture registers, which are stored on the stack. However, we pushed the initial value of the current position, so the stack pointer is offset by one word from where we expect.
The fix is to pop the saved value *before* subtracting the length.
With this fix, we pass all the test262 tests for look-behind assertions, dotAll, and unicode property escapes. (I will turn them on in a separate bug.)
Depends on D73112
Differential Revision: https://phabricator.services.mozilla.com/D73113
This is very similar to wcosta's earlier patch, with a few adjustments to overcome
special cases:
- remove the wrench override of adb path; handle in config instead
- fix taskcluster config syntax in a couple of places
- add android-sdk-linux fetch for test-verify
Differential Revision: https://phabricator.services.mozilla.com/D73157
This adds a new property lsan-disabled to wpt metadata files, which takes
a boolean to determine if lsan should be entirely disabled for that directory.
Differential Revision: https://phabricator.services.mozilla.com/D73918
Yura Zenevich
Ted Campbell
Chris Martin
Jon Coppeard
Botond Ballo
Benjamin Beurdouche
Jeff Muizelaar
Kirk Steuber
Kagami Sascha Rosylight
AaryanDewan
Tim Nguyen
Andi-Bogdan Postelnicu
Dale Harvey
Tom Schuster
Steve Fink
Narcis Beleuzu
Byron Campen [:bwc]
Martin Stransky
André Bargull
John Lin
Kartikaya Gupta
Iain Ireland
Emilio Cobos Álvarez
Sebastian Hengst
Geoff Brown
James Graham