Because we only ever run one subconfigure, the machinery to execute
several is not useful anymore. Inlining it allows to simplify the code
too, because it doesn't need to be generic anymore. This also removes
the last remaining bits of acwinpaths.m4.
Also remove now unused support for --list in build/subconfigure.py.
Depends on D16380
Differential Revision: https://phabricator.services.mozilla.com/D16381
--HG--
extra : moz-landing-system : lando
I think it's a little bizarre for this to be part of the standard, but if it
weren't there, I wouldn't know it was safe to do this.
Differential Revision: https://phabricator.services.mozilla.com/D14511
--HG--
extra : moz-landing-system : lando
Bug 1464869 resulted in blank lines being inserted between comments
and the classes they describe in the gdb unwinder code. This patch
changes most of these comments into doc strings instead.
MozReview-Commit-ID: 6XQwheUNRxI
Differential Revision: https://phabricator.services.mozilla.com/D7174
--HG--
extra : moz-landing-system : lando
No change in behavior that I'm aware of. It should be correct either way,
since the object is guaranteed to be an object created just so by code
elsewhere in the Streams implementation. But the intended purpose of
GetPropertyPure is in a fast path, backstopped by an actual GetProperty, not
for cases like this.
Differential Revision: https://phabricator.services.mozilla.com/D14505
--HG--
extra : moz-landing-system : lando
I don't know why it's OK to drop this particular error; my guess is that the
error was already reported previously, when the stream became errored, and
there's no point reporting it again.
Differential Revision: https://phabricator.services.mozilla.com/D14496
--HG--
extra : moz-landing-system : lando
Because the .xdata format on ARM64 can only encode sizes up to 1M (much too small for our JIT code regions), we register a function table callback to provide RUNTIME_FUNCTIONs at runtime. Windows doesn't seem to care about the size fields on RUNTIME_FUNCTIONs that are created in this way, so the same RUNTIME_FUNCTION can work for any address in the region. We'll set up a generic one in RegisterExecutableMemory and the callback can just return a pointer to it.
Differential Revision: https://phabricator.services.mozilla.com/D16261
--HG--
extra : moz-landing-system : lando
This patch removes the StopWatch code that was used in the first version of
about:performance, and not being used anymore.
Differential Revision: https://phabricator.services.mozilla.com/D7453
--HG--
extra : moz-landing-system : lando
These tests mostly use either the debugger (requires separate compartemnts for
debugger/debuggee) or require a new compartment for things like nukeAllCCWs().
Differential Revision: https://phabricator.services.mozilla.com/D16172
--HG--
extra : moz-landing-system : lando
I added this optimization in bug 1299107 to share more shapes across
compartments. Unfortunately this doesn't play well with same-compartment
realms (ICs can misbehave) because it relies on compartments being isolated
from each other.
I think we should remove this optimization:
* Fixing the IC issue is impossible without deoptimizing everything.
* I added it mainly for chrome globals. The shared-JSM-global work has eliminated
the need for this there.
* Same-compartment realms win memory back by eliminating CCWs etc.
* It's quite a lot of complicated code.
Differential Revision: https://phabricator.services.mozilla.com/D16170
--HG--
extra : moz-landing-system : lando
We want to use this shell flag in automation. Some globals really need their
own compartment so tests can use newGlobal({newCompartment: true}) to opt-out.
Differential Revision: https://phabricator.services.mozilla.com/D16166
--HG--
extra : moz-landing-system : lando
Bindgen is only used when building js or toolkit, so we only need to
include the configure part in js/moz.configure, which is included in
both cases.
Depends on D16293
Differential Revision: https://phabricator.services.mozilla.com/D16294
--HG--
extra : moz-landing-system : lando
