Moving recordErrors in DelazifyTask::Create() to after the allocation of the
task allows us to use the ErrorContext in the task to store the errors instead
of having to move them into the task later, and we only miss the allocation of
the task itself (which wasn't recorded in the errors anyway).
Differential Revision: https://phabricator.services.mozilla.com/D151878
hadErrors() is more descriptive than `errors().empty()`.
Access to the pending errors list is pushed down to OffThreadErrorContext,
because that's the only context where it is used.
Differential Revision: https://phabricator.services.mozilla.com/D151669
This removes a lot of plumbing allocators through function parameters but still
maintains the ErrorContext and allocator as separate concepts.
At this point, there is no need for the type or instances of ErrorContext and
ErrorAllocator to vary independently.
Differential Revision: https://phabricator.services.mozilla.com/D151610
ErrorAllocator was only ever used with ErrorContext, so no need for templating.
linkWithJSContext() better describes what it is doing, since JSContext needs its
errors_ field filled in, at least until we can replace it with a different
allocator for functions that are called during compilation.
getAllocator() is a convenience so we don't have to add a separate allocator
parameter everywhere we pass an ErrorContext and also need an allocator.
Differential Revision: https://phabricator.services.mozilla.com/D151609
ReportErrorVA(), ReportErrorNumberVA(), and ReportErrorNumberUCArray(), and
ReportErrorNumberUTF8Array() use JSContext for rooting, so they will have to be
called from the main thread. The only reason to pass ErrorContext to them would
be for consistency with the other error reporting functions.
Differential Revision: https://phabricator.services.mozilla.com/D151608
ErrorAllocator is an adapter that allows MallocProvider to delegate
to polymorphic Contexts. MallocProvider provides a well-known interface,
but doesn't support polymorphism, so we resort to templating and adapters
like this.
JS::CharsToNewUTF8CharsZ() needs a definition in CharacterEncoding.cpp,
so for now I explicitly instantiate it for ErrorAllocator<JSContext>.
A better solution would be to move the definition to a header, but that's
a bigger task.
Differential Revision: https://phabricator.services.mozilla.com/D151179
OffThreadErrorContext::setAllocator() needs to setOffThreadFrontendErrors on
the JSContext because CompileToStencilTask::parse() uses it to allocate the
CompilationInput.
Differential Revision: https://phabricator.services.mozilla.com/D150647
I could get rid of OffThreadErrorContext::cx_ by subclassing from
MallocProvider, but I don't think that would work since
OffThreadErrorContext has a vtable and MallocProvider does a
static_cast to get the client pointer.
OffThreadFrontendErrors moved to ErrorContext.h to avoid
recursive header inclusion.
Differential Revision: https://phabricator.services.mozilla.com/D150645
Fixes jit-test. Probably needs coordination with ESMification efforts.
It looks like JS::CompileModule() would be called from the main thread, so
it should use GeneralErrorContext.
Differential Revision: https://phabricator.services.mozilla.com/D151178
DummyTokenStreams created when handling RegEx should be happening at JS
runtime, so on main thread (unless maybe workers?); so GeneralErrorContext is
appropriate there.
Differential Revision: https://phabricator.services.mozilla.com/D150644
This allows the Parser creator to provide the ErrorContext appropriate
for the situation (main thread or helper thread). For now, we just use
a flexible implementation.
I think the lifetime of the ErrorContext is the same as the Parser, so
putting the ErrorContext on the stack when the Parser is, too, should be
safe.
Differential Revision: https://phabricator.services.mozilla.com/D150642
Temporarily passing JSAllocator* to ExpandErrorArgumentsVA in
ReportCompileWarning(). It is only used for allocation and for AutoSuppressGC.
Differential Revision: https://phabricator.services.mozilla.com/D150641
Implement the new dominant axis locking mode for the apz.axis_lock.mode
preference. When using this mode, we do not use the traditional axis locks.
Instead we only consider the input pan displacement for the axis with
a larger value, zeroing out the displacement on the opposite axis.
Differential Revision: https://phabricator.services.mozilla.com/D152104
Root cause: the global object can be null but I wasn't checking for it so it
caused a crash. I don't remember under what conditions it can be null but I saw
I had checked for null when I wrote Performance::Mark and remember debugging it
so it makes sense to do so here as well.
Differential Revision: https://phabricator.services.mozilla.com/D151960
Use a larger stack size on macOS 13 for the Wifi monitor thread to accommodate Core WLAN code allocating 217K+ on the stack.
Differential Revision: https://phabricator.services.mozilla.com/D152555
Bryan Thrall
hanna alemu
Dan Robertson
Yury Delendik
Dale Harvey
Joel Maher
smolnar
Emilio Cobos Álvarez
Dan Minor
Florian Quèze
Csoregi Natalia
Oriol Brufau
Mike Conley
Michael Comella
Sebastian Hengst
Jared Wein
Mark Banner
Haik Aftandilian
ffxbld