This patch effectively synchronizes code from old-configure.in to
js/src/old-configure.in. Before, the top-level configure would set
MOZ_NO_DEBUG_RTL when using MOZ_MEMORY on Windows. This would get
inherited when the top-level configure invoked the js/src configure.
Since js/src's configure didn't have the same code, we never set
MOZ_NO_DEBUG_RTL when running a standalone js/src configure. This caused
the debug runtime to be used in standalone SpiderMonkey builds.
There is still some code in the root old-configure.in around CRT
handling that js/src/old-configure.in doesn't have. This will
likely get consolidated as part of the conversion to configure.py.
MozReview-Commit-ID: CD834DhIlLS
--HG--
extra : rebase_source : 9252c0166acf7ac5c760d530ca1dcbb740adb3e2
extra : source : a007293e6ab06df203c09a5535f5591667c45af2
This patch effectively synchronizes code from old-configure.in to
js/src/old-configure.in. Before, the top-level configure would set
MOZ_NO_DEBUG_RTL when using MOZ_MEMORY on Windows. This would get
inherited when the top-level configure invoked the js/src configure.
Since js/src's configure didn't have the same code, we never set
MOZ_NO_DEBUG_RTL when running a standalone js/src configure. This caused
the debug runtime to be used in standalone SpiderMonkey builds.
MozReview-Commit-ID: CD834DhIlLS
--HG--
extra : rebase_source : c0ae3a5308ff9525c63b949a40504180c47ce5fb
It's an opt-in flag that allows to display where the build is in
terminal window titles. The fact that it's opt-in and likely unknown
makes it very low-value, and the fact that it was added in an era where
builds were not very well parallelized made it have a meaning, but now
that builds are parallelized, its meaningfulness is diminished.
Let's just remove it.
There can be multiple compartments within the same zone, only one of which is a
debuggee. In this scenario, CCWs from other compartments into the debuggee
compartment should be traced and treated as roots. Therefore, dealing with CCWs
at the JS::Zone level is incorrect, and this patch changes the granularity level
to JSCompartments. If you look at the callers and uses of the function, it makes
much more sense now.
Additionally, it renames `JS_TraceIncomingCCWs` to `JS::TraceIncomingCCWs`.
--HG--
rename : devtools/shared/heapsnapshot/tests/gtest/DoesCrossZoneBoundaries.cpp => devtools/shared/heapsnapshot/tests/gtest/DoesCrossCompartmentBoundaries.cpp
rename : devtools/shared/heapsnapshot/tests/gtest/DoesntCrossZoneBoundaries.cpp => devtools/shared/heapsnapshot/tests/gtest/DoesntCrossCompartmentBoundaries.cpp
With all the things that still depend on all the variables derived from
--host and --target in both old-configure and moz.build, we still need
to keep variables such as OS_ARCH, OS_TARGET, CPU_ARCH, OS_TEST, etc.
Eventually, we'd settle on the output of split_triplet.
This /tries/ to preserve the current values for all these variables,
while also trying to make things a little more consistent. It also
effectively rejects OSes such as HPUX or AIX, because it is unclear
the decades old accumulated scripts related to them still do anything
useful, and we might as well have them start again from scratch, which,
in the coming weeks, will be even easier.
Follow the DataView functions and use Tonumber to coerce index arguments on the
load/store functions. Throw a RangeError when we see a non-integer index or a
number outside the range of the array.
See https://github.com/tc39/ecmascript_simd/issues/328
MozReview-Commit-ID: IpHkfPyywU0
Using a simple |const char*| is more memory-efficient than allocating a
JS string. We still have to allocate the JS string for passing things
into JS, but ideally we will be able to move the point of allocation
much closer to where it's actually needed, rather than indiscriminantly
doing it all the time.
Gregory Szorc
Mike Hommey
Steve Fink
Hannes Verschore
Benjamin Bouvier
Nicolas B. Pierron
Terrence Cole
Jan de Mooij
Jon Coppeard
Heiher
Nick Fitzgerald
Tooru Fujisawa
Daniel Holbert
Eric Faust
Jason Orendorff
Wes Kocher
Jakob Olesen
Nathan Froyd