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.
