MinGW has two threading models: win32 API based, which disables std::thread,
and POSIX based which enables it but requires an emulation library (winpthreads).
Rather than attempting to switch to pthread emulation at this point, we are
disabling the std::thread based assertion checking for WeakPtr on MinGW.
MozReview-Commit-ID: BmHo70n6AuK
--HG--
extra : rebase_source : 08495775b2925a797c8098216911d30c0b79ef3d
You'd think that this would throw off the assertion stacks in nsTraceRefcnt::WalkTheStack. But as far as I can tell, it was already setting |skipFrames| too high!
On top of that, the function was getting out-of-lined in some instances already. It really should have been MOZ_ALWAYS_INLINE_EVEN_DEBUG.
MozReview-Commit-ID: J2FZmi0pKro
--HG--
extra : rebase_source : 20e5be9f8c21637a28435f47b8ab2de101825679
Not only does this trim the code, it also makes MOZ_RELEASE_ASSERT follow the advice of MOZ_CRASH earlier in the file:
* If we're a DEBUG build and we crash at a MOZ_CRASH which provides an
* explanation-string, we print the string to stderr. Otherwise, we don't
* print anything; this is because we want MOZ_CRASH to be 100% safe in release
* builds, and it's hard to print to stderr safely when memory might have been
* corrupted.
MozReview-Commit-ID: Kuxzn1v9Vfs
--HG--
extra : rebase_source : 5c6efe7cb9adb1c366b423d6ff8f95002512985c
I left gMozCrashReason visible (but not meaningfully used) in all builds, in order to match the behavior of Assertions.cpp, and to avoid more #ifdef clutter in nsExceptionHandler.cpp.
MozReview-Commit-ID: smoFkddGzd
--HG--
extra : rebase_source : 498f927f62fc944edf254c2ff3b115131367a506
The C versus C++ distinction was only there so that Android could make sure it used the global ::abort. I didn't see the need to maintain the distinction for Windows. (Besides, with this change we're no longer doing textual inclusion of "TerminateProcess" in the macro, so people can't take over the name.)
Linux's abort sequence wasn't long enough to be troublesome, so I left it alone.
MozReview-Commit-ID: Ah5XtWpevGz
--HG--
extra : rebase_source : 37c3fb4c50bcba8e48c6a965a02e3f8608940538
Making this constructor non-explicit will permit automatic conversions from
'nullptr' into RefPtr types, which I think are not dangerous.
The one spot that this affects is in 'UserDataType nsBaseHashtable::Get(KeyType)',
which does a 'return 0;' into the UserDataType, which could be a bool, an int, a
RefPtr or other. I'm changing that into a C++11 "value initialization", which
falls back to "zero initialization" for PODs: 'return UserDataType{};'.
Also fixed the comment to clarify not-found return values, as Get(KeyType) was
not only used for pointers anyway.
MozReview-Commit-ID: F41VlvTNOZU
--HG--
extra : rebase_source : 71d5dacac75ca188e5c55d45f48a5fca76d953c6
Added constructor and operator= from a nullptr, bypassing the incoming pointer
check.
Note that the constructor is 'explicit', because one particular use in
nsBaseHashtable is doing a 'return 0' into a templated type that is a RefPtr in
many cases. Making this new constructor explicit removes it from consideration
in this case.
As it's not strictly necessary to have it MOZ_IMPLICIT (but could still be
nice), I will tackle that in the patch after next.
Also changed all zeroes into nullptr when relevant in RefPtr.h (other system-
wide affected files will be updated in following patch.)
MozReview-Commit-ID: Ds4CEv9hZWI
--HG--
extra : rebase_source : f4ec156b13ea3bdcf32b1a33d76ff9771ad6d1dc
Since |T*| converts into |const T*|, if we want to rewrite code such as:
void DoSomething(const T*, size_t);
void DoSomethingElse(T* x, size_t len)
{
...
DoSomething(x, len);
}
to use ranges:
void DoSomething(Range<const T>);
void DoSomethingElse(Range<T> x)
{
...
DoSomething(x);
}
we need to ensure this conversion works. gsl::span<T> already provides
something like this as well.
