I did not add a separate macro for `MOZ_TRIVIAL_DTOR` as I could not really
think of a use case for it. Let me know if you prefer that I add it as a
distinct macro.
Differential Revision: https://phabricator.services.mozilla.com/D39719
--HG--
extra : moz-landing-system : lando
We don't support MSVC anymore, clang-cl ignores these pragmas, and
nobody actually used the macros anyway.
Depends on D38887
Differential Revision: https://phabricator.services.mozilla.com/D38888
--HG--
extra : moz-landing-system : lando
Change the `ResultImplementation` and `Result` constructors to accept success
values by `const` reference. This makes it possible for `Result` to carry
`MOZ_NON_PARAM` types as success values.
Differential Revision: https://phabricator.services.mozilla.com/D36682
--HG--
extra : moz-landing-system : lando
This also implicitly deletes its copy-assignment operator and copy-constructor,
which is great since it's a huge footgun.
Differential Revision: https://phabricator.services.mozilla.com/D36549
--HG--
extra : moz-landing-system : lando
Patch to use std::move when passing AllocPolicy instances to constructors. This also fixes HashTable move constuction/assignment that previously PodAssigned the whole object including the AllocPolicy base.
Differential Revision: https://phabricator.services.mozilla.com/D36175
We can't generate a constexpr uint64_t containing the bits for positive/negative infinity, because of a (very sensible) static_assert in SpecificNaNBits. This patch adds support to FloatingPoint.h for infinity. The next patch will use it to make JS::InfinityValue constexpr (to match JS::NaNValue).
Differential Revision: https://phabricator.services.mozilla.com/D29869
--HG--
extra : moz-landing-system : lando
Turns out we do have saturated arithmetic in mfbt, I just missed it.
Also, use just an uint32 for the heuristic. Text length is a uint32 anyway, and
it's unlikely we want to decide anything when the value is over the max uint32
value.
Differential Revision: https://phabricator.services.mozilla.com/D34496
--HG--
extra : moz-landing-system : lando
Define the Variant::addTagToHash method, which perturbs a hash value according
to the variant's current alternative's tag. This makes it easier to avoid
collisions in variants in which different alternatives might hash similarly.
Tests included.
Differential Revision: https://phabricator.services.mozilla.com/D28768
--HG--
extra : moz-landing-system : lando
Reducing the sleep to 0 on Android results in a dramatic reduction in run time, and the test
passes consistently.
Differential Revision: https://phabricator.services.mozilla.com/D28296
--HG--
extra : moz-landing-system : lando
stderr does not go anywhere by default on Android. Debugging output is
conventionally sent to the Android log via special functions like
__android_log_print.
We already have logic for handling this in nsCRTGlue's printf_stderr, but
I don't think we can use that in MFBT.
Differential Revision: https://phabricator.services.mozilla.com/D26985
--HG--
extra : moz-landing-system : lando
We want MOZ_Crash frames to stay out of Taskcluster logs even on debug builds. Perhaps you could say, _especially_ on debug builds.
Differential Revision: https://phabricator.services.mozilla.com/D26352
--HG--
extra : moz-landing-system : lando
It would be helpful if MOZ_CRASH_UNSAFE_PRINTF would do its crashing inline at the caller, so that CI failure logs can blame the right code.
Before this patch, MOZ_CRASH_UNSAFE_PRINTF calls MOZ_CrashPrintf, which does the printf work and crashes.
This patch pulls out the crashing piece at the end, so that MOZ_CrashPrintf only does the printf work, and returns the string to the caller, who will MOZ_Crash inline.
Differential Revision: https://phabricator.services.mozilla.com/D25329
--HG--
extra : moz-landing-system : lando
Mechanical change from Matcher::match(...) to Matcher::operator()(...).
This will now permit the use of generic lambdas, and facilitate the
implementation of multi-lambda match.
Differential Revision: https://phabricator.services.mozilla.com/D24889
--HG--
extra : moz-landing-system : lando
Convenience functions to erase elements based on a predicate, or by comparing to
a value. They are optimized to use the minimal amount of moves necessary.
Differential Revision: https://phabricator.services.mozilla.com/D25016
--HG--
extra : moz-landing-system : lando
Templated pointer can't match |nullptr|, we should add overloading for
std::nullptr_t specifically to be able to support |nullptr|.
Differential Revision: https://phabricator.services.mozilla.com/D24925
--HG--
extra : moz-landing-system : lando
Bug 1463035 exists to remove it entirely, because as mentioned in bug
1238661 comment 4, we don't actually need this workaround anymore. But
that bug has been blocked for a while because the Android emulator
images we use for testing, for some reason, use a kernel older than any
real device using the same version of Android would use.
Let's however fix the problems it causes with GCC on non-Android ARM
Linux by making it Android-only, rather than removing it entirely.
Differential Revision: https://phabricator.services.mozilla.com/D24134
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
MOZ_THREAD_LOCAL currently assumes its invocations live in the global
namespace, which may not always be true, e.g. when declaring a static
class member whose enclosing class lives in `namespace mozilla` or
similar. We should qualify the name lookups required to always start
from the global namespace to avoid such problems.
With `ac_add_options --enable-project=tools/crashreporter` in a
mozconfig, `./mach build` builds minidump_stackwalk, dump_syms
and fileid.
One caveat is that due to limitation in how the build system works
currently, it's cumbersome to keep dump_syms as a host program for
Gecko, and to make it a target program for this project. For now,
keep it as a host program. We're not going to use it on automation,
but it's still convenient to have for quick local builds (I've had
to resort to awful hacks downstream).
Differential Revision: https://phabricator.services.mozilla.com/D16299
--HG--
extra : moz-landing-system : lando
Fails with clang trunk:
"type of UTF-8 string literal will change from array of const char to array of const char8_t in C++2a"
otherwise
Differential Revision: https://phabricator.services.mozilla.com/D14696
--HG--
extra : moz-landing-system : lando
As discussed in the previous commit message, HashTableEntry wastes space
for common entry types. This commit reorganizes the internal storage to
store all the hashes packed together, followed by all the entries, which
eliminates the aforementioned waste.
HashTableEntry's data layout currently wastes a fair amount of space due
to ABI-mandated padding. For instance, HashTableEntry<T*> on a 64-bit
platform looks like:
class HashTableEntry {
HashNumber mKeyHash;
// Four bytes of wasted space here to pad mValueData to the correct place.
unsigned char mValueData[sizeof(T*)];
};
This wasted space means that sets of pointers backed by
mozilla::HashTable waste a quarter of their entry storage space. Maps
of pointers to pointers waste a sixth of their entry storage space.
We'd like to fix this by packing all the cached hashes together,
followed by all the hash table entries.
As a first step to laying out the hash table storage differently, we
have to make HashTable not access entries directly, but go through an
abstraction that represents the key and the entry. We call this
abstraction "slots". This commit is similar to the change done for
PLDHashTable previously.
Parts of HashTable still work in terms of Entry; the creation and
destruction of tables was not worth changing here. We'll address that
in the next commit.
We do this to make our lives easier in later patches; this check
guarantees that we don't need padding between the block of cached hash
values and the block of entries immediately after it.
As discussed in the previous commit message, HashTableEntry wastes space
for common entry types. This commit reorganizes the internal storage to
store all the hashes packed together, followed by all the entries, which
eliminates the aforementioned waste.
HashTableEntry's data layout currently wastes a fair amount of space due
to ABI-mandated padding. For instance, HashTableEntry<T*> on a 64-bit
platform looks like:
class HashTableEntry {
HashNumber mKeyHash;
// Four bytes of wasted space here to pad mValueData to the correct place.
unsigned char mValueData[sizeof(T*)];
};
This wasted space means that sets of pointers backed by
mozilla::HashTable waste a quarter of their entry storage space. Maps
of pointers to pointers waste a sixth of their entry storage space.
We'd like to fix this by packing all the cached hashes together,
followed by all the hash table entries.
As a first step to laying out the hash table storage differently, we
have to make HashTable not access entries directly, but go through an
abstraction that represents the key and the entry. We call this
abstraction "slots". This commit is similar to the change done for
PLDHashTable previously.
Parts of HashTable still work in terms of Entry; the creation and
destruction of tables was not worth changing here. We'll address that
in the next commit.
We do this to make our lives easier in later patches; this check
guarantees that we don't need padding between the block of cached hash
values and the block of entries immediately after it.
- 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
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13193
--HG--
extra : moz-landing-system : lando
These macros tend to be handled quite poorly since the clang-format
tokenizer cannot figure out how to handle them.
Differential Revision: https://phabricator.services.mozilla.com/D13179
--HG--
extra : moz-landing-system : lando
HasFreeLSB currently fails for any types that map to void*. Unless we fix this,
we can't use certain types as template parameters for mozilla::Result.
Differential Revision: https://phabricator.services.mozilla.com/D12358
--HG--
extra : moz-landing-system : lando
Rename MOZ_MakeRecordReplayWrapper to MOZ_MAKE_RECORD_REPLAY_WRAPPER so
that clang-format doesn't mangle code.
Differential Revision: https://phabricator.services.mozilla.com/D12233
--HG--
extra : moz-landing-system : lando
The current rust panic hook keeps a string for the crash reporter, and
goes on calling the default rust panic hook, which prints out a crash
stack... when RUST_BOOTSTRAP is set *and* when that works. Notably, on
both mac and Windows, it only really works for local builds, but fails
for debug builds from automation, although on automation itself, we also
do stackwalk from crash minidumps, which alleviates the problem.
Artifact debug builds are affected, though.
More importantly, C++ calls to e.g. MOZ_CRASH have a similar but
different behavior, in that they dump a stack trace on debug builds, by
default (with exceptions, see below for one). The format of those stack
traces is understood by the various fix*stack*py scripts under
tools/rb/, that are used by the various test harnesses both on
automation and locally.
Additionally, the current rust panic hook, as it calls the default rust
panic hook, ends up calling abort() on non-Windows platforms, which ends
up being verbosely redirected to mozalloc_abort per
https://dxr.mozilla.org/mozilla-central/rev/237e4c0633fda8e227b2ab3ab57e417c980a2811/memory/mozalloc/mozalloc_abort.cpp#79
which then calls MOZ_CRASH. Theoretically, /that/ would also print a
stack trace, but doesn't because currently the stack trace printing code
lives in libxul, and MOZ_CRASH only calls it when compiled from
libxul-code, which mozalloc_abort is not part of.
With this change, we make the rust panic handler call back into
MOZ_CRASH directly. This has multiple advantages:
- This is more consistent cross-platforms (Windows is not special
anymore).
- This is more consistent between C++ and rust (stack traces all look
the same, and can all be post-processed by fix*stack*py if need be)
- This is more consistent in behavior, where debug builds will show
those stack traces without caring about environment variables.
- It demangles C++ symbols in rust-initiated stack traces (for some
reason that didn't happen with the rust panic handler)
A few downsides:
- the loss of demangling for some rust symbols.
- the loss of addresses in the stacks, although they're not entirely
useful
- extra empty lines.
The first should be fixable later one. The latter two are arguably
something that should be consistent across C++ and rust, and should be
changed if necessary, independently of this patch.
Depends on D11719
Depends on D11719
Differential Revision: https://phabricator.services.mozilla.com/D11720
--HG--
extra : moz-landing-system : lando
Because we don't really need all this repetition.
Depends on D11718
Depends on D11718
Differential Revision: https://phabricator.services.mozilla.com/D11719
--HG--
extra : moz-landing-system : lando
Ideally, we'd want the function to stay in Assertions.cpp, but that's
only part of MFBT proper, and that doesn't have access to WalkTheStack
like MOZ_CRASH has from being in Assertion.h, when included from Gecko
code. Moving WalkTheStack to mozglue, putting it close together with
MozStackWalk would be prefered, but that causes problems linking MFBT
tests (which don't have access to mozglue), and other things.
Overall, this was too deep a rabbit hole, and moving MOZ_CrashOOL to
Assertions.h is much simpler. Since it's essentially the same as
MOZ_CRASH, except it allows non-literal strings, we can make it inlined,
and leave it to the compiler to drop the filename argument when it's not
used.
Differential Revision: https://phabricator.services.mozilla.com/D11718
--HG--
extra : moz-landing-system : lando
Aaron Klotz
Nathan Froyd
Jed Davis
Sylvestre Ledru
Tom Prince
Csoregi Natalia
Jim Blandy
Kyle Huey
Emilio Cobos Álvarez
Jon Coppeard
Kagami Sascha Rosylight
Narcis Beleuzu
shindli
Ciure Andrei
Jeff Walden
Iain Ireland
Mike Hommey
Mihai Alexandru Michis
arthur.iakab
Andi-Bogdan Postelnicu
Brian Hackett
Jean-Yves Avenard
Ryan VanderMeulen
Geoff Brown
Botond Ballo
Cameron McCormack
Daniel Varga
David Major
Jan Varga
Jeff Gilbert
Gerald Squelart
Oana Pop Rus
Alex Gaynor
Sebastian Hengst
Cosmin Sabou
violet
dOn'tReallycAre
Steve Fink
Valentin Gosu
Coroiu Cristina
Boris Zbarsky
Gurzau Raul
Jan de Mooij
Nicholas Nethercote
Chris Peterson
Tooru Fujisawa
Andrew McCreight
Ehsan Akhgari
Olli Pettay
Henri Sivonen
Benjamin Bouvier
Ted Campbell