mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Export of internal Abseil changes

Browse source 
--
7f6c15aadc4d97e217dd446518dbb4fdc86b36a3 by Derek Mauro <dmauro@google.com>:

Upgrade GCC automated testing to use GCC 9.2 and Cmake 3.16.2

PiperOrigin-RevId: 288488783

--
a978cee848d3cf65b0826c981bfd81022fc36660 by Abseil Team <absl-team@google.com>:

Removing formatting traits that were only used internally. ON_CALL/EXPECT_CALL do a sufficient job here.

PiperOrigin-RevId: 288386509

--
fdec6f40293d5883220f1f0ea1261f7c5b60a66e by Derek Mauro <dmauro@google.com>:

Upgrade MacOS tests to use Bazel 2.0.0

PiperOrigin-RevId: 288373298

--
465865c4123e9481ab50ea0527e92b39519704dd by Derek Mauro <dmauro@google.com>:

Changes to support GCC 9
 * Fix several -Wredundant-move warnings
 * Remove FlatHashMap.Any test, which basically doesn't work on any platform
   any more (see https://cplusplus.github.io/LWG/lwg-active.html#3121)
 * Fix a constant sign-compare warning
 * Conditionally compile out the PoisonHash test which doesn't build

PiperOrigin-RevId: 288360204

--
57c4bb07fc58e7dd2a04f3c45027aab5ecaccf25 by Andy Soffer <asoffer@google.com>:

Deflaking MockingBitGen test. Because MockingBitGen can return random values,
it is inherently flaky. For log-unifrom, 2040 is a common enough value that
tests failed unreasonably frequently. Replacing it with a significantly larger
value so as to be much less common. 50000 is a good choice because it is (tied for) the least likely to occur randomly from this distribution, but is still in the distribution.

PiperOrigin-RevId: 288360112

--
86f38e4109899d972de353b1c556c018cfe37956 by Matt Calabrese <calabrese@google.com>:

Remove construction tests for the internal `CompressedTuple<std::any>` instantiation. This was not guaranteed to work for the reasons that `std::tuple<std::any>` copy construction does not actually work by standard specification (some implementations introduce workarounds for this). In GCC9, `CompressedTuple<std::any>` and `std::tuple<std::any>` both fail for the same reasons, and a proper "fix" requires updating `std::any`, which is out of our control.

PiperOrigin-RevId: 288351977
GitOrigin-RevId: 7f6c15aadc4d97e217dd446518dbb4fdc86b36a3
Change-Id: I5d5c62bd297dc0ff1f2970ff076bb5cd088a7e4c
This commit is contained in:
Abseil Team 2020-01-07 06:56:49 -08:00 • committed by Derek Mauro
parent a048203a88
commit 63ee2f8877
22 changed files with 386 additions and 76 deletions
Download patch file Download diff file Expand all files Collapse all files

5
absl/random/bit_gen_ref.h
View file

@ -132,7 +132,7 @@ namespace random_internal {
template <>
struct DistributionCaller<absl::BitGenRef> {
template <typename DistrT, typename... Args>
template <typename DistrT, typename FormatT, typename... Args>
static typename DistrT::result_type Call(absl::BitGenRef* gen_ref,
Args&&... args) {
auto* mock_ptr = gen_ref->mocked_gen_ptr_;
@ -140,7 +140,8 @@ struct DistributionCaller<absl::BitGenRef> {
DistrT dist(std::forward<Args>(args)...);
return dist(*gen_ref);
} else {
return mock_ptr->template Call<DistrT>(std::forward<Args>(args)...);
return mock_ptr->template Call<DistrT, FormatT>(
std::forward<Args>(args)...);
}
}
};