We should have the same public API available whenever possible, and make
it a no-op or make it throw immediately if JS was built without support
for it, instead of showing or hiding the API in header files using
configure macros. Otherwise embedders can easily get mismatches between
a library with functionality and header files without it, or vice versa.
There was no good reason why JS_GetErrorType() was nightly-only API, so
this also enables it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D52124
--HG--
extra : moz-landing-system : lando
We should have the same public API available whenever possible, and make
it a no-op or make it throw immediately if JS was built without support
for it, instead of showing or hiding the API in header files using
configure macros. Otherwise embedders can easily get mismatches between
a library with functionality and header files without it, or vice versa.
There was no good reason why JS_GetErrorType() was nightly-only API, so
this also enables it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D52124
--HG--
extra : moz-landing-system : lando
This macro isn't defined anywhere and doesn't seem to do anything. It
affects the oom-backtraces property of the build configuration object in
the testing functions, but since the macro is never defined, it seems to
be always set to false anyway, so just hardcode it.
Differential Revision: https://phabricator.services.mozilla.com/D51769
--HG--
extra : moz-landing-system : lando
This file provides the implementation of js/Utility.h, so it should be renamed
to match the header name.
Differential Revision: https://phabricator.services.mozilla.com/D51378
--HG--
rename : js/src/jsutil.cpp => js/src/util/Utility.cpp
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Added thread type as ThreadType enum. Default is ThreadType::THREAD_TYPE_NONE. RunnableTasks must specify their own thread type.
Differential Revision: https://phabricator.services.mozilla.com/D33818
--HG--
extra : moz-landing-system : lando
Added 'RunnableTask' struct to Utility.h to unify HelperThread task types in a way that can be exposed to XPCOM thread pools. Re-implemented tasks within native HelperThreads using their runnableTask method.
Differential Revision: https://phabricator.services.mozilla.com/D24921
--HG--
extra : moz-landing-system : lando
Currently, some of the JS allocators accept an 'arena' argument, but some
don't. This change makes it so they all do. This is nice for consistency, but
it also feeds into Bug 1052579, which will need to use arenas for JSString
backing buffers.
Differential Revision: https://phabricator.services.mozilla.com/D19717
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
These functions incorrectly passed sizeof(T) instead of 1, so we would allocate sizeof(T) * sizeof(T) bytes instead of sizeof(T) bytes. This was used for PcScriptCache where we would allocate a few extra megabytes due to this bug. The patch changes PcScriptCache to use UniquePtr + MakeUnique.
Differential Revision: https://phabricator.services.mozilla.com/D4343
--HG--
extra : amend_source : e9e3e906ac649a4b05d91c10e60bc10bc858fb98
Currently we have three ways of representing hash values.
- uint32_t: used in HashFunctions.h.
- PLDHashNumber: defined in PLDHashTable.{h,cpp}.
- js::HashNumber: defined in js/public/Utility.h.
Functions that create hash values with functions from HashFunctions.h use a mix
of these three types. It's a bit of a mess.
This patch introduces mozilla::HashNumber, and redefines PLDHashNumber and
js::HashNumber as synonyms. It also changes HashFunctions.h to use
mozilla::HashNumber throughout instead of uint32_t.
This leaves plenty of places that still use uint32_t that should use
mozilla::HashNumber or one of its synonyms, but I didn't want to tackle that
now.
The patch also:
- Does similar things for the constants defining the number of bits in each
hash number type.
- Moves js::HashNumber from Utility.h to HashTable.h, which is a better spot
for it. (This required changing the signature of ScrambleHashCode(); that's
ok, it'll get moved by the next patch anyway.)
MozReview-Commit-ID: EdoWlCm7OUC
--HG--
extra : rebase_source : 5b92c0c3560eb56850cd8832f8ee514d25e3c16f
This patch adds new functions taking the arena parameter rather than overloading
existing functions, because there are already overloads of calloc that take
two size_t parameters (which arena_id_t is an alias for), so it couldn't have
been done that way, and malloc and realloc needed to be consistent with calloc.
MozReview-Commit-ID: 1MUXoCUgJWO
--HG--
extra : rebase_source : 16261ba4e802efa0bc65878d490ae9b62aa35797
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
