Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
This has some minor fixes to ensure we create the object in the callee's realm
for MCreateThisWithTemplate and MCreateThisWithProto. It also fixes Baseline to
actually create a template object for Ion for cross-realm calls.
Differential Revision: https://phabricator.services.mozilla.com/D19760
--HG--
extra : moz-landing-system : lando
Environment shapes always use the max number of fixed slots before using
dynamic slots (see EmptyEnvironmentShape). We can take advantage of this in
the JITs and eliminate the calls to EnvironmentCoordinateToEnvironmentShape.
Differential Revision: https://phabricator.services.mozilla.com/D19361
--HG--
extra : moz-landing-system : lando
Not every ARM Linux distro (all of them tier-3 apart from Android) has
a sys/user.h that provides the necessary structures for us to emulate
unaligned FP accesses. Raspbian is a case in point; the only user.h
on the system is some generic glibc thing that is completely wrong for
ARM.
We can't really hope to #ifdef our way out of this -- for example,
there does not seem to be a reliable preprocessor name for Raspbian,
nor is there a canonical preprocessor name that sys/user.h exports
when the desired structures are defined.
Therefore, add some comments to explain the problem and introduce a
choke point that tier-3 porters can use if they run into the problem.
Differential Revision: https://phabricator.services.mozilla.com/D19637
--HG--
extra : rebase_source : 06f1218fabb04028e56f98b0a314b91ddd81ea96
extra : amend_source : e0a7a373bf0ddb510ecc4b5f8b364cba92d705f5
This is a follow-up to the previous part, which actually changes one of
these callers to use Array<nsIIDRef> instead of [array] nsIIDPtr.
From doing this patch, it seems like we should consider changing
the type `nsIIDRef` to instead simply be `nsIID`, and treat it more like
the `AString` types from the POV of XPIDL. `nsIIDPtr` would then
continue to exist for backwards compatibility, but we can probably
remove almost all current consumers over time.
Depends on D19175
Differential Revision: https://phabricator.services.mozilla.com/D19176
--HG--
extra : moz-landing-system : lando
Currently the [ref] and [ptr] types share the same underlying
implementation. This is unfortunate, and can cause correctness problems
with outparam refs (as an example).
By using the same tools used to allow other larger objects (such as
jsid, nsTArray, and nsString) to be stored directly in the nsXPTCVariant
object, this patch directly stores the nsID in the nsXPTCVariant object
when calling from JS into C++.
Using this new strategy avoids an nsID* allocation every time we pass
one over XPConnect, and should also allow us to simplify callers.
In addition, some special casing is added to xpidl to make it possible
to use the nsid reference type objects directly inside of Array<T>,
which will allow us to remove `[array] nsIIDPtr` callers.
Differential Revision: https://phabricator.services.mozilla.com/D19175
--HG--
extra : moz-landing-system : lando
Modify the Debugger API implementation to ensure that debugger code's promise
activity (resolving promises; running reaction jobs) cannot interfere with the
debuggee's.
Specifically, ensure that there is an `AutoDebuggerJobQueueInterruption` in
scope at every site in the Debugger implementation that might invoke a debugger
hook function. This saves the debuggee's job queue, emplaces a fresh empty
queue, lets the hooks run, drains the queue, and then restores the debuggee's
original queue.
Since we must already mark sites that could invoke hooks with
`EnterDebuggeeNoExecute`, we ensure our job queue protection coverage is
complete statically by having `EnterDebuggeeNoExecute`'s constructor require a
reference to an `AutoDebuggerJobQueueInterruption`.
Differential Revision: https://phabricator.services.mozilla.com/D17547
--HG--
extra : moz-landing-system : lando
Define a new RAII class, AutoDebuggerJobQueueInterruption, to save and restore
the current ECMAScript job queue, to protect the debuggee's job queue from
activity that occurs in debugger callbacks. Add a new method to the JS::JobQueue
abstract base class, saveJobQueue, to support AutoDebuggerJobQueueInterruption.
Comments on AutoDebuggerJobQueueInterruption provide details.
Implement saveJobQueue for SpiderMonkey's internal job queue and for Gecko's job
queue in CycleCollectedJSContext.
Differential Revision: https://phabricator.services.mozilla.com/D17546
--HG--
extra : moz-landing-system : lando
While the behavior of ECMAScript Promises and their associated job queue is
covered by the ECMAScript standard, the HTML specification amends that with
additional behavior the web platform requires. To support this, SpiderMonkey
provides hooks the embedding can set to replace SpiderMonkey's queue with its
own implementation.
At present, these hooks are C-style function-pointer-and-void-pointer pairs,
which are awkward to handle and mistake-prone, as passing a function the wrong
void* is not a type error. Later patches in this series must add new hooks,
making a bad situation worse.
A C++ abstract base class is a well-typed alternative. This introduces a new
`JS::JobQueue` abstract class, and adapts SpiderMonkey's internal job queue and
Gecko's customization to use it. `GetIncumbentGlobalCallback` and
`EnqueuePromiseJobCallback` become virtual methods.
Within SpiderMonkey, the patch gathers the various fields of JSContext that
implement the internal queue into their own type, js::InternalJobQueue. Various
jsfriendapi functions become veneers for calls to methods specific to the
derived class. The InternalJobQueue type itself remains private to SpiderMonkey,
as it uses types like TraceableFifo, derived from Fifo, that are not part of
SpiderMonkey's public API.
Within Gecko, CycleCollectedJSContext acquires JS::JobQueue as a private base
class, and a few static methods are cleaned up nicely.
There are a few other hooks defined in js/public/Promise.h that might make sense
to turn into virtual methods on JobQueue. For example,
DispatchToEventLoopCallback, used for resolving promises of results from
off-main-thread tasks, is probably necessarily connected to the JobQueue
implementation in use, so it might not be sensible to set one without the other.
But it was left unchanged to reduce this patch's size.
Differential Revision: https://phabricator.services.mozilla.com/D17544
--HG--
extra : moz-landing-system : lando
Bug 1526508 - add profiler markers for importing a JS module, loading a JS XPCOM component or a subscript
Differential Revision: https://phabricator.services.mozilla.com/D19228
--HG--
extra : moz-landing-system : lando
Until now, SpiderMonkey's debugger interfaces have generally relied on the
implicitly-defined 'entrypoint' concept. This meant that assigning a given
bytecode a position also automatically meant that it behaved like a breakpoint.
This both made it hard to maintain, and hard to define user's expectations
because there could potentially be many more breakpoints than users would
actually want.
This patch adds an official concept of recommended breakpoint and recommended
step-next pause locations, and APIs for users to query for them. The
expectation being that users would now use this metadata in debugging UIs.
Differential Revision: https://phabricator.services.mozilla.com/D15994
--HG--
extra : moz-landing-system : lando
This brings SpiderMonkey more in line with V8 for the positions that it uses for expressions
nested within statements. We generally prefer to use the expression's own location
rather than the location of the statement, in the majority of cases.
Differential Revision: https://phabricator.services.mozilla.com/D15993
--HG--
extra : moz-landing-system : lando
Before this patch, changing FILES_PER_UNIFIED_FILES in the directory would
require changes to all the files that defined the sandbox variable, which is
a bit misleading. Exporting the variable prevents this, and it is safe to use
because it doesn't escape the scope of the js/src build directory.
Differential Revision: https://phabricator.services.mozilla.com/D19647
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
This is just a bit of cleanup I'd noticed while writing new implementations of these.
Differential Revision: https://phabricator.services.mozilla.com/D17659
--HG--
extra : moz-landing-system : lando
When we mark call expressions as breakpoints, we want to make it as likely
as possible that the call has its own unique positon. The existing logic
means that it is more likely that the beginning of a call will align
with the start of an expression statement or other debuggable step point.
By using the property-access location, we're less likely to collide.
Thid also adds a new bytecodes that were missed in the original code that
added this position handling logic.
Differential Revision: https://phabricator.services.mozilla.com/D17661
--HG--
extra : moz-landing-system : lando
This is just a bit of cleanup I'd noticed while writing new implementations of these.
Differential Revision: https://phabricator.services.mozilla.com/D17659
--HG--
extra : moz-landing-system : lando
I added ARM64_WIN64 to every line that mentioned X86_WIN32 and X86_WIN64.
This makes sure the allocation routines do the proper VirtualProtect on the trampolines.
Differential Revision: https://phabricator.services.mozilla.com/D19567
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
Problem: When a stack chunk had to be popped as part of a control flow
instruction, the amount to pop was not always computed as a multiple
of ChunkSize. The reason is that the fixed amount of stack that
should not be popped isn't necessarily a multiple of ChunkSize, yet
this was assumed.
A small adjustment to the calculation fixes that.
Also added an assertion that would have caught this problem more
easily.
Also did some desirable drive-by fixes to clarify documentation and to
factor the resulting code.
The TC sets up a situation where we require a chunk to be created and
then destroyed in the 'else' arm of the 'if', at the same time as the
fixed amount of stack is not a multiple of ChunkSize.
Differential Revision: https://phabricator.services.mozilla.com/D19470
--HG--
extra : rebase_source : 08e8bde715995babd535d73c691335be9fef983a
Mike Hommey
Jan de Mooij
Gurzau Raul
Andy Wingo
Tooru Fujisawa
Lars T Hansen
Csoregi Natalia
shindli
Brindusan Cristian
Paul Bone
Nika Layzell
Jim Blandy
Florian Quèze
Bogdan Tara
Logan Smyth
Benjamin Bouvier
Peeyush Kushwaha
Boris Zbarsky
Nicolas B. Pierron
Razvan Maries
Andreea Pavel
Robin Templeton
Sean Stangl
David Major
Jonathan Kingston