Given that we have a SegmentedVector of nsCOMPtrs, it's probably worth
avoiding copying it.
MozReview-Commit-ID: GHyfVLrdnlQ
--HG--
extra : rebase_source : 75df805d8b2df32b76ee77b95ced625f20331744
This is drop-in replacements of std::ifstream and std::ofstream, but supports
widechar filenames on Windows. This is just an alias of std::ofstream on other
platforms.
MozReview-Commit-ID: FHNatG5595k
--HG--
extra : rebase_source : 0805153dd13907a6c3b6971bfc0b499a31416b9a
extra : intermediate-source : 3113df1e69bf7444105953df8610b8bbf5d4d41e
extra : source : 750263b126963d2634a89de0a2aac63efa4b49e6
In Bug 1393538 I renamed MOZ_STATIC_ASSERT_UNUSED_ATTRIBUTE to MOZ_UNUSED_ATTRIBUTE,
moved it out of it's #define depth, and used it in toolkit. I also orphaned a
comment.
This was wrong. MOZ_UNUSED_ATTRIBUTE was basically identical to MOZ_MAYBE_UNUSED
which exists in Attributes.h (because it is an attribute, not an assertion.)
Undo that wrong thing: restore MOZ_STATIC_ASSERT_UNUSED_ATTRIBUTE to the correct
place, have toolkit use the correct macro, and remove MOZ_UNUSED_ATTRIBUTE.
MozReview-Commit-ID: 5BWWsXgbm9i
--HG--
extra : rebase_source : d07156068c877bf57d400bc6a71e115b7f1aef31
Currently only |value_type| is implemented.
MozReview-Commit-ID: 1mejzvkuako
--HG--
extra : rebase_source : 69e08073adbb9a866db26e515702a0659ece0a70
extra : intermediate-source : 3696381ddfdc19ab2f901ca4247e1cb4efb27731
extra : source : 35d760da1d73dd51614f434c26e5ce80ff690829
clang-cl fails to build without this change due to ambiguous call.
MozReview-Commit-ID: 22x5PCsG221
--HG--
extra : rebase_source : 93d2d50abc126286ad78c1f3700fe358c507a826
extra : intermediate-source : a9c64eaa326a2c694456d2e8907074f75b66c645
extra : source : c0b55d2093f59a8dabf2640106befa0dae516906
Apply 63a7f34fee
to our copy of lz4.h to allow to flag the lz4 symbols as not exported.
--HG--
extra : rebase_source : d9aafb04a56c0ae3620e0c873f77d124386a41c4
The library was added in bug 1160285 for webapprt, and webapprt was
removed in bug 1238079.
--HG--
extra : rebase_source : 8e47523263eb53707b0d916cc550418f1bc646ef
We out-of-line the relevant functions because release assertions can
generate quite a bit of code, and we'd rather let the compiler determine
if these functions should be inlined now.
MakeNotNull is similar to UniquePtr, in that it combines the infallible
allocation and construction of an object on the heap and wraps the (raw or
smart) pointer into a NotNull.
It skips the unnecessary null check from WrapNotNull, and removes the usual
naked 'new' used in many WrapNotNull calls.
MozReview-Commit-ID: UwCrhDnkUg
--HG--
extra : rebase_source : 5a027165fc17ed748783c7ffda03eb421865ad6e
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
Delete Span's implicit constructors for char* and char16_t* pointers to avoid accidental construction in cases where a pointer does not point to a zero-terminated string. Use the MakeStringSpan() function instead.
I deleted both the const and non-const char* and char16_t* constructors, in the name of cross-compiler consistency. If we only delete the const char* and char16_t* constructors, for some reason, MSVC complains that `Span<char> s(charArray)` uses a deleted constructor while clang nor gcc permit it. I don't know if this is a compiler bug in MSVC or clang and gcc.
Also, do not permit MakeSpan() for string literals (const char and char16_t arrays) because the Span length would include the zero terminator, which may surprise callers. Use MakeStringSpan() to create a Span whose length that excludes the string literal's zero terminator or use the MakeSpan() overload that accepts a pointer and length and specify the string literal's full length.
The following Span usages are prevented:
Span<const char> span("literal"); // error
Span<char> span(charArray); // error
Span<const char> span;
span = "literal"; // error
span = charArray; // error
MakeSpan("literal"); // error
The following Span usages are still permitted:
assert(MakeStringSpan("literal") == 8); // OK: span length is calculated with strlen() and excludes the zero terminator
MakeStringSpan(charArray); // OK: span length is calculated with strlen() and excludes the zero terminator
MakeSpan(charArray); // OK: span length is the char array size including any zero terminator
MozReview-Commit-ID: Et71CpjsiyI
--HG--
extra : rebase_source : f6f8bdb28726f0f2368fdfdd039fb1d7dcf2914e
extra : source : 0547d8924ffc7713d6cf32cc06eeeaf00e0d69a3
ThreadLocalKeyStorage uses Thread Local APIs that are declared in
processthreadsapi.h (although it's more common to just include
windows.h). If a caller wants to use this class, it is their
responsibility to include an appropriate header before including
ThreadLocal.h
MozReview-Commit-ID: GO5dHKVWpZO
--HG--
extra : rebase_source : ff8d6cda1eed7bd9d54745c869b4e47a895b605a
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.
