Bug 1480595 - make TimeStamp compilable for AArch64 Windows; r=glandium We don't have to check whether AArch64 systems have a stable counter; they are all specified to do so in the architecture reference manual.

Bug 1421501 - build integration for vendored msgpack r=glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r=glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1483761 - Enable clang's -Wtautological-overlap-compare warning. r=glandium -Wtautological-overlap-compare is an opt-in warning added in clang 3.5. It warns about overlapping comparisons that are always true or false, such as: if (x > 4 || x < 10) {} // warning! always true int b = x < 2 && x > 5; // warning! always false return x > 4 || x < 10; // warning! always true https://clang.llvm.org/docs/DiagnosticsReference.html#wtautological-overlap-compare There are currently no -Wtautological-overlap-compare warnings in mozilla-central. Differential Revision: https://phabricator.services.mozilla.com/D3477

Bug 1483761 - Enable clang's -Wshadow-field-in-constructor warnings. r=glandium This opt-in warning catches bugs where a constructor modifies a constructor parameter that shadows member variable name. The code probably intended to change the member variable value, not the paramter. There are currently no -Wshadow-field-in-constructor warnings in mozilla-central. https://clang.llvm.org/docs/DiagnosticsReference.html#wshadow-field-in-constructor-modified Differential Revision: https://phabricator.services.mozilla.com/D3822

Bug 1483761 - Enable clang's -Wfloat-(overflow|zero)-conversion warnings. r=glandium -Wfloat-overflow-conversion detects when a constant floating point value is converted to an integer type and will overflow the target type. https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-overflow-conversion -Wfloat-zero-conversion detects when a non-zero floating point value is converted to a zero integer value. https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-zero-conversion There are currently no -Wfloat-overlap-conversion warnings in mozilla-central. There is one -Wfloat-zero-conversion warning in a webrtc test. It doesn't block enabling this check because the webrtc tests are not compiled with warnings-as-errors. media/webrtc/trunk/webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller_unittest.cc:255:54 [-Wfloat-zero-conversion] implicit conversion from 'const float' to 'int' changes non-zero value from 0.045000002 to 0 We can't enable all -Wfloat-conversion warnings (for any implicit conversion of a floating-point number into an integer) because there are currently over 1400 warnings. I spot checked a few of these -Wfloat-conversion warnings. I didn't find any obvious bugs, but there is some suspicious code, such as implicit conversions of floats to bools. Differential Revision: https://phabricator.services.mozilla.com/D3476

Bug 1483761 - Enable clang's -Wc++2a-compat warnings. r=glandium Warn about C++ constructs whose meaning change in C++2a. https://clang.llvm.org/docs/DiagnosticsReference.html#wc-2a-compat So far the only -Wc++2a-compat check that I know of is for valid pre-C++2a code that inadvertently parses as C++2a's new <=> "spaceship" comparison operator. `f<&A::operator<=>();` is an example of a warning reported for a real project on GitHub. That code can be rewritten as `f< &operator<= >();`. There are currently no -Wc++2a-compat warnings in mozilla-central. Differential Revision: https://phabricator.services.mozilla.com/D3478

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1483835: Default to clang-cl and lld-link in local Windows builds. r=glandium

Bug 1483835: Default to clang-cl and lld-link in local Windows builds. r=glandium

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1481978 - Change IPC CloseSuperfluousFds to prevent accidentally heap-allocating closures. r=glandium Closures are nice but -- as pointed out in bug 1481978 comment #2 -- it's a footgun to take a std::function argument in a context where heap allocation isn't safe. Fortunately, non-capturing closures convert to C function pointers, so a C-style interface with a void* context can still be relatively ergonomic.

Bug 1479878 Add a --skip-revert option to build-clang.py r=glandium Differential Revision: https://phabricator.services.mozilla.com/D2580

Bug 1476147 - Use path.isfile() instead of patch.exists() in which(). r=glandium This excludes directories, and returns true only if it's an executable file. Differential Revision: https://phabricator.services.mozilla.com/D3366

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1421501 - build integration for vendored msgpack r?glandium MozReview-Commit-ID: 4AKDbOU4aWx

Bug 1421501 - vendor msgpack from https://github.com/msgpack/msgpack-c/commit/2c4f2b890ef1546fc022d270d11e657f6fc8022f r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1421501 - vendor msgpack 3.0.1 r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1479599 Recognize webextensions in packager r=glandium MozReview-Commit-ID: KethvfCTf6G

Bug 1421501 - vendor msgpack 3.0.1 r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1481097 - mfbt: Assert we're compiling with gcc 6.1 or later. r=glandium Firefox currently requires gcc 6.1 or later (as of bug 1444274). MozReview-Commit-ID: CaJwpUgntxn

Bug 1421501 - vendor msgpack 3.0.1 r?glandium MozReview-Commit-ID: 9vzQOuszf3p

Bug 1481097 - mfbt: Assert we're compiling with gcc 6.1 or later. r?glandium Firefox currently requires gcc 6.1 or later (as of bug 1444274). MozReview-Commit-ID: CaJwpUgntxn

Bug 1480553 - part 3 - add mappings for aarch64 in Windows configure paths; r=glandium We need to add mappings for target.cpu to MSVC's arm64 name for determining various paths, and we need to add an extra case to get_vc_paths so the compiler can find all the necessary DLLs.

Bug 1480553 - part 2 - add a case for aarch64* when setting MIDL_FLAGS; r=glandium

Bug 1480553 - part 1 - add Windows-specific aarch64 macro detection; r=glandium MSVC doesn't define __aarch64__, but uses its own symbol instead.

Bug 1444141 - part 4 - make the JS engine depend on Rust; r=chmanchester,glandium,jorendorff The Rust dependency in Firefox has been limited to Firefox builds by virtue of having the Rust check in a Firefox-specific location, toolkit/moz.configure. For JS to start depending on Rust, we need to move that check to a location where a standalone JS engine build will pick up the Rust check.

Bug 1480315 - Fix coredump caused by getenv. r=glandium

Bug 1478561 - Bump OOM hook rustc version check to check for greater than 1.30.0-alpha. r=glandium MozReview-Commit-ID: ESiK7tqHMT0

Bug 1451891 - Fix race conditions in __wrap_dlerror. r=glandium a=pascalc __wrap_dlerror uses a single pointer for all threads, which means one thread could get the dlerror result from another thread. Normally this wouldn't cause crashes. However, because dlerror results come from a per-thread buffer, if a thread exits and our saved dlerror result came from that thread, the saved pointer could then refer to invalid memory. The proper way to fix this is to use TLS and have a per-thread pointer for __wrap_dlerror. However, instead of using up a TLS slot, this patch keeps the single pointer for custom messages, and fallback to per-thread dlerror call for system messages. While the race condition still exists, I think the risk is acceptable. Even when races occur, they should no longer cause crashes. MozReview-Commit-ID: 4hGksidjiVz

Bug 1478560 - Fix the compiling error of the struct nsXPTCVariant. r=glandium

Bug 1451891 - Fix race conditions in __wrap_dlerror; r=glandium __wrap_dlerror uses a single pointer for all threads, which means one thread could get the dlerror result from another thread. Normally this wouldn't cause crashes. However, because dlerror results come from a per-thread buffer, if a thread exits and our saved dlerror result came from that thread, the saved pointer could then refer to invalid memory. The proper way to fix this is to use TLS and have a per-thread pointer for __wrap_dlerror. However, instead of using up a TLS slot, this patch keeps the single pointer for custom messages, and fallback to per-thread dlerror call for system messages. While the race condition still exists, I think the risk is acceptable. Even when races occur, they should no longer cause crashes. MozReview-Commit-ID: 4hGksidjiVz

Bug 1473266 - Remove in-tree newline_if_not_empty. r=Yoric,glandium

Bug 1451891 - Fix race conditions in __wrap_dlerror; r?glandium __wrap_dlerror uses a single pointer for all threads, which means one thread could get the dlerror result from another thread. Normally this wouldn't cause crashes. However, because dlerror results come from a per-thread buffer, if a thread exits and our saved dlerror result came from that thread, the saved pointer could then refer to invalid memory. The proper way to fix this is to use TLS and have a per-thread pointer for __wrap_dlerror. However, instead of using up a TLS slot, this patch keeps the single pointer for custom messages, and fallback to per-thread dlerror call for system messages. While the race condition still exists, I think the risk is acceptable. Even when races occur, they should no longer cause crashes. MozReview-Commit-ID: 4hGksidjiVz

Bug 1476098 - Add Google and Mozilla API keys to ASan Nightly. r=glandium MozReview-Commit-ID: AAQWWiHeLB0