RegsToPreserve must contain the correct float registers *and* be immune to
PushRegsInMask stripping out the SIMD registers in non-SIMD builds before
it performs register set reduction. The correct mask to start with is
therefore AllMask, not AllVector128Mask, as the latter is stripped down to
an empty set, not reduced down to the set of doubles.
This bug came in with the SIMD patch and affects non-SIMD builds on x64
as well as all builds on x86.
Differential Revision: https://phabricator.services.mozilla.com/D74825
To make sure that `<input>` elements with `pattern` attributes update their validation state (`:invalid`) properly, nsContentUtils::IsPatternMatching needs to be able to distinguish between parsing errors caused by an invalid pattern, vs parsing errors caused by OOM/overrecursion.
This patch also fixes up the places inside the new regexp engine where we can throw over-recursed to make sure that we set the right flag on the context, then fixes regexp/huge-01.js (and the binast variants) to accept a different error message.
Differential Revision: https://phabricator.services.mozilla.com/D74499
Introduce JS::IsBaseTraceType to check if a type is the canonical type
associated with a TraceKind. Use this with SFINAE to make footguns turn into
compile errors.
Differential Revision: https://phabricator.services.mozilla.com/D74869
The `{Cell,TenuredCell,GCCellPtr}::{is,as}<T>()` methods can be footguns if
called on derived types. Only the TraceKind must match which is rarely what
is expected.
Differential Revision: https://phabricator.services.mozilla.com/D74868
Use the FunctionFlags in the FunctionBox to distinguish explict, inferred,
and guessed atom types. When inter-converting between FunctionBox and
JSFunctions we now sync all types of atoms.
Note that if the function pre-exists, we still propagate the name directly.
The code coverage initialization is triggered by fullyInitFromStencil which
is not fully deferred yet, so we need to the setInferredName to take effect
before then.
Differential Revision: https://phabricator.services.mozilla.com/D74728
Stack normalization is uber-slow on emulator because it relies on
regexes that are compiled to native instructions which are then
emulated. That makes stack normalization very slow too, and as it's
very hot some tests will time out nearly always.
This patch inserts a simple cache for previously matched strings in
stack normalization to avoid the regex engine altogether. This speeds
up normalization and hence stack matching greatly (I observed a factor
of four speedup per test iteration on an arm-sim noopt debug build for
ion-error-ool.js).
I also attempted some other fixes (filtering on simple strings,
avoiding regex.replace, etc) but caching is by far the most effective
fix, and with caching in place the other fixes still don't really move
the needle.
Depends on D74220
Differential Revision: https://phabricator.services.mozilla.com/D74607
Now that branchValueIsNurseryCell is as efficient as branchValueIsNurseryObject
we no longer need branchValueIsNurseryObject.
Depends on D74649
Differential Revision: https://phabricator.services.mozilla.com/D74650
It's more efficient now to check for all GC things with a single branch instead of
checking for object/string/BigInt separately. This generates more compact code with
fewer branches and is also more maintainable.
Depends on D74648
Differential Revision: https://phabricator.services.mozilla.com/D74649
With the following changes Object.prototype.toString is not using the JSClass' name
anymore. This means we now fail to detect opaque wrappers, because they just get the default string: [object Object]
Differential Revision: https://phabricator.services.mozilla.com/D74016
This patch adds a C++ libfuzzer target for differential testing between the interpreter and compiler of the new regexp engine.
Differential Revision: https://phabricator.services.mozilla.com/D73768
We are adding support for the dotAll (/s) RegExp flag, so the list of expected properties on the RegExp prototype has to be updated.
Differential Revision: https://phabricator.services.mozilla.com/D74149
ASAN found a leak.
We destroy the isolate with a level of indirection through RegexpAPI so that JSContext doesn't have to be able to see the full definition of Isolate.
Differential Revision: https://phabricator.services.mozilla.com/D74151
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
To make sure that `<input>` elements with `pattern` attributes update their validation state (`:invalid`) properly, nsContentUtils::IsPatternMatching needs to be able to distinguish between parsing errors caused by an invalid pattern, vs parsing errors caused by OOM/overrecursion.
This patch also fixes up the places inside the new regexp engine where we can throw over-recursed to make sure that we set the right flag on the context, then fixes regexp/huge-01.js (and the binast variants) to accept a different error message.
Differential Revision: https://phabricator.services.mozilla.com/D74499
With this patch the list of sanctioned identifiers in the C++ and JS source
files is automatically generated from the yaml file. And we also check that
the ICU data filter file includes all necessary unit resources.
This also renames `MeasureUnit::subtype` to `MeasureUnit::name` for clarity.
Differential Revision: https://phabricator.services.mozilla.com/D73031
This performs JSScript allocation by consuming the Stencil. For now we leave
handling of delazification compiles alone.
Differential Revision: https://phabricator.services.mozilla.com/D74572
Use the ScriptStencil copy of flags which also includes computed flags. We
also fix up the flag computation in the SmooshFrontend to be more complete
and explicit.
Differential Revision: https://phabricator.services.mozilla.com/D74571
Instead, have a batch process at end of bytecode emission just before reading
out the result script. We do this for functions that are inner to a script we
are generating bytecode code. These functions may still be lazy but they are
potentially exposed in JSOp::Lambda/LambdaArray ops.
Differential Revision: https://phabricator.services.mozilla.com/D74569
Razvan Maries
Tom Schuster
Lars T Hansen
Iain Ireland
Ted Campbell
Dorel Luca
Sebastian Hengst
André Bargull
Yoshi Cheng-Hao Huang
Jan de Mooij
Andrew McCreight
Kannan Vijayan