Exceptions:
- AutoSetNewObjectMetadata and its related type are still exclusively about objects.
- JSCompartment::objectMetadataTable is still only about objects.
- the ObjectMetadataMap type still only has objects as keys.
Non-exceptions:
The builder type, and the JSCompartment member:
ObjectMetadataCallback -> AllocationMetadataBuilder
objectMetadataCallback -> allocationMetadataBuilder
jsfriendapi.h interface:
SetObjectMetadataCallback -> SetAllocationMetadataBuilder
GetObjectMetadata -> GetAllocationMetadata
JSCompartment methods:
hasObjectMetadataCallback -> hasAllocationMetadataBuilder
getObjectMetadataCallback -> getAllocationMetadataBuilder
setObjectMetadataCallback -> setAllocationMetadataBuilder
forgetObjectMetadataCallback -> forgetAllocationMetadataBuilder
addressOfMetadataCallback -> addressOfMetadataBuilder
Shell and testing functions:
SavedStacksMetadataCallback -> SavedStacksMetadataBuilder
ShellObjectMetadataCallback -> ShellAllocationMetadataBuilder
EnableShellObjectMetadataCallback -> EnableShellAllocationMetadataBuilder
enableShellObjectMetadataCallback -> enableShellAllocationMetadataBuilder
GetObjectMetadata -> GetAllocationMetadata
getObjectMetadata -> getAllocationMetadata
Delayed metadata collection:
shouldDelayMetadataCallback -> shouldDelayMetadataBuilder
JSCLASS_DELAY_METADATA_CALLBACK -> JSCLASS_DELAY_METADATA_BUILDER
suppressObjectMetadataCallback -> suppressAllocationMetadataBuilder
--HG--
extra : rebase_source : 54af5a56edd9b39466fa418f7a72fc586d0482d3
- HW_THREADS doesn't appear to be doing anything.
- USE_ARM_KUSER is not used since bug 675078. This also removes the configure
flag that sets it.
- HAVE_SETBUF and HAVE_SNPRINTF are leftover from bug 944935.
- MOZ_MEMORY_GONK is leftover from bug 804303.
- DEVELOPER_OPTIONS, INTEL_CC, INTEL_CXX, MOZ_ENABLE_QTMOBILITY,
GTK_CONFIG are or even were never used outside configure.
- MOZ_PROFILELOCKING which gradually became a no-op over the years. This
also removes the configure flag that sets it.
- XULRUNNER_STUB_NAME is xulrunner-only, and xulrunner is gone. This
also removes the configure flag that sets it.
- The only use of MOZ_CAN_RUN_PROGRAMS was removed in bug 780561.
- AR_LIST and AR_DELETE have not been used since bug 584474.
- MOZ_COMPONENT_NSPR_LIBS is leftover from bug 1036894.
- MOZ_PNG_ARM_NEON_CHECK is not used since bug 980488.
- MOZ_WEBRTC_LEAKING_TESTS has been no-oped by bug 825510.
- VPX_NEED_OBJ_INT_EXTRACT and NO_INTEGRATED_AS_CFLAGS are not used since
bug 1151175.
- WCHAR_CFLAGS is not used since bug 904985.
In bug 1260996, we straightened things up for the host flags on cross
compile builds, where the situation was that they were effectively empty
by default, and that hasn't changed.
While working on bug 1260996, it has become clear that there is no much
point in setting the host flags from the target flags on non cross
compile builds, especially when the target flags come from the environment.
That creates a discrepancy with cross compilation builds for no real
reason, and there are effectively too few host things to build that it
would matter anyways. The flags that do matter are the ones for C++11,
C99, and optimisations, and they all are set independently of what is
being removed here.
Previously, every test and support file would be synced to the objdir
when running any test. Now that only those support files and tests requested
are synced, we note support files required beyond those in a test's
directory in ini manifests.
MozReview-Commit-ID: EmlDz9d4lqt
js::ClassSpec is often all null. When it's not all null, it's often duplicated
among classes. By pulling it out into its own struct, and using a (possibly
null) pointer in js::Class, we can save 138 KiB per process on 64-bit, and half
that on 32-bit.
--HG--
extra : rebase_source : 852ac6770ace46958d018107e78c5c44ebd6528a
A number of ObjectOps instances are more exposed than they need to be. This
patch converts several to be either private (within a class) or static (within
a file).
--HG--
extra : rebase_source : f994ac229caa799da66d920d748ec1154fc9206f
Gonk, Android, and the generic cross-compilation setup all were using a
different yet similar way to prefix the toolchain. The latter was even
wrong, since the target and target alias usually don't match actual
toolchain prefixes (which don't include the machine part of the target).
Note that this removes force-setting cross_compiling to yes in
old-configure, which wasn't working because every AC_TRY_COMPILE
resets it with $ac_cv_prog_cc_cross or $ac_cv_prog_cxx_cross.
