There are use cases for wanting a specific TLS implementation
independently of whether __thread or thread_local are supported.
This is one step in that direction, making the
pthread_{get,set}specific-based implementation available independently.
We still keep everything under the mozilla::detail namespace because
it's still better if people don't try to use mozilla::ThreadLocal
directly.
--HG--
extra : rebase_source : 095b95a577b85efaaf2f3c0b7c3ac968ff711738
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 9eb7334b6dde05f9af0eaea4184e532c69d0264e
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : 674277bac4fc979f2e483a77b5ef1495baccc7fe
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 1d40653b8117e28d8633134f379540c3c517a306
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : f84c5799c305a4a3b7dc5deb727a05d4d537bb15
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 7f2c03d6ba5c1da5d8badb0de710b7900e9d00c1
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : b7d502754a764670e291acdd56726948db935497
Also adds a mozilla/ResultExtensions.h header to define the appropriate
conversion functions for nsresult and PRResult. This is in a separate header
since those types are not available in Spidermonkey, and this is the pattern
other *Extensions.h headers follow.
Also removes equivalent NS_TRY macros and WrapNSResult inlines that served the
same purpose in existing code, and are no longer necessary.
MozReview-Commit-ID: A85PCAeyWhx
--HG--
extra : rebase_source : a5988ff770888f901dd0798e7717bcf6254460cd
This allows MOZ_TRY and MOZ_TRY_VAR to be transparently used in XPCOM methods
when compatible Result types are used.
Also removes a compatibility macro in SimpleChannel.cpp, and an identical
specialization in AddonManagerStartup, which are no longer necessary after
this change.
MozReview-Commit-ID: 94iNrPDJEnN
--HG--
extra : rebase_source : 24ad4a54cbd170eb04ded21794530e56b1dfbd82
When used as an error value, nsresult should never be NS_OK, which means that
we should be able to safely pack simple nsresult Result values into a single
word.
MozReview-Commit-ID: GJvnyTPjynk
--HG--
extra : rebase_source : ab5a64b545dfbfe9bbef167f8b63ecbf00b16e07
This makes sure that:
* We don't define `MOZ_GLUE_IN_PROGRAM` so that everything in mozglue gets
defined.
* `MFBT_API`'s symbol export rules match `JS_PUBLIC_API` and `EXPORT_JS_API`.
* We add mozglue to SpiderMonkey's `USE_LIBS` when jemalloc is disabled.
/home/worker/workspace/build/src/mozglue/build/WindowsDllBlocklist.cpp:816:1: error: 'noreturn' function does return [-Werror]
MozReview-Commit-ID: SYgPDW0sMV
--HG--
extra : rebase_source : 27b1dda404b3fc5fab95dd524677387bad921751
nsQueryReferent is defined as an nsCOMPtr_helper, which implies that
calling its operator() method requires a virtual call. While
nsQueryReferent is marked `final`, compiler inlining decisions make it
impossible to de-virtualize the call to operator(). However, we have
many other classes returned by do_* functions that nsCOMPtr handles
directly, requiring no extra virtual calls, and we can give
nsQueryReferent the same treatment.
The generic fallback MOZ_FALLTHROUGH definition is insufficient for GCC 7 and
above, resulting in --enable-warnings-as-errors builds failing.
The check for clang support is changed to use the __has_cpp_attribute macro,
which is more robust than checking the __cplusplus version.
Also, MOZ_FALLTHROUGH is now only defined in C++ code, since GCC errors out if
it encounters a scoped attribute being used with __has_cpp_attribute in C code.
No C code uses MOZ_FALLTHROUGH or derivatives at the moment.
MozReview-Commit-ID: 4nKFBRD5jSF
--HG--
extra : rebase_source : 0c37ae39c806ca24a3271d3ec19531dd16e05daf
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
Changes made:
* Add IPC::ParamTraits as a friend to mozilla::Variant in Variant.h.
This is required so that `tag` can be accessed in the
IPC::ParamTraits specialization.
* Add a IPC::ParamTraits specialization to IPCMessageUtils.h.
MozReview-Commit-ID: B3pGrZE1z0O
--HG--
extra : rebase_source : cb73873b87401846f79e124249c7ce00dff2de77
These macros can be used in cases where the `mozilla` namespace might
not refer to the toplevel `mozilla` namespace that was intended. To
ensure that the macros always refer to the `mozilla` namespace in the
global namespace, use the appropriate qualification.
