--
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
--
d3a10a071226497cd34be0f41cb55449193b7172 by Andy Soffer <asoffer@google.com>:
Removing formatting traits that were only used internally. ON_CALL/EXPECT_CALL do a sufficient job here.
PiperOrigin-RevId: 288342973
--
df8180038ea36a0876a84fdc163d1319a611f9db by Greg Falcon <gfalcon@google.com>:
Add CI testing for alternate options.h settings.
PiperOrigin-RevId: 288323951
GitOrigin-RevId: d3a10a071226497cd34be0f41cb55449193b7172
Change-Id: I26c75a1ededd52dd2c5a4c50e220d0b8a52d5c7c
This contains a little tool that can make requests to the Google Maps
API for distance matrix lookups from Fundu results to Schiphol Airport
and Amsterdam Centraal.
<3 edef!
Currently we just pick randomly between the cave and dungeon level
generators. There's a lot of bugs here, but it's *sorta* working, so I'm
leaving it as is.
This prevents them from being inlined. On gcc 9, this reduces the
stack size needed for
nix-instantiate '<nixpkgs>' -A texlive.combined.scheme-full --dry-run
from 12.9 MiB to 4.8 MiB.
(cherry picked from commit cb90e382b5b6e177ea902b3909fd1897643ae3cd)
If the user invokes nix with --trace-function-calls it means that they
want to see the trace.
(cherry picked from commit 619cc4af855fab7b0400586a4fd40745b23e72ad)
Add a data structure, based on the zipper comonad, which provides
support for multiple levels, each of which is its own entity map. The
current level is provided by coreturn, which the `entities` lens has
been updated to use. Nothing currently supports going up or down levels
yet - that's coming next.
This script rebuilds & activates system configuration based on the
hostname.
Currently since there is only one host this isn't particularly
interesting.
`s3:ListObjects` isn't a real IAM action, but _is_ the name of an S3 API method. `s3:ListBucket` is the relevant action for that method.
https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazons3.html
(cherry picked from commit c92ea927e508f3c06b6b3ee68e1f0565264cac2c)
We're calling `wait4path` on the full, resolved `@bindir@/nix-daemon` path.
That means we're hardcoding something like:
/bin/wait4path /nix/store/zs9c5xhp3zv9p23qnjxp87nl5injsi1i-nix-2.3/bin/nix-daemon && /nix/var/nix/profiles/default/bin/nix-daemon
That seems unnecessarily fragile.
It might be better to wait4path on the path we intend to call.
(cherry picked from commit 8c4a5e7ba1990348b9497c0fc4dc236dda3e7986)
On Catalina, the /nix filesystem might not be mounted at start time.
To avoid this service not starting, we need to keep the launch agent
outside of the Nix store. A wait4pid will hold for our /nix dir to be
mounted.
Fixes#3125.
(cherry picked from commit 0847f2f1b3145a62dc34707ba788275ce6b6fc57)
The tmpDirInSandbox is different when in sandboxed vs. non-sandboxed.
Since we don’t know ahead of time here whether sandboxing is enabled,
we need to reset all of the env vars we’ve set previously. This fixes
the issue encountered in https://github.com/NixOS/nixpkgs/issues/70856.
(cherry picked from commit 499b0388759db0f9f385da402a4bba551268aa99)
The intent of the code was that if the window size cannot be determined,
it would be treated as having the maximum possible size. Because of a
missing assignment, it was actually treated as having a width of 0.
The reason the width could not be determined was because it was obtained
from stdout, not stderr, even though the printing was done to stderr.
This commit addresses both issues.
(cherry picked from commit c935ad3f025d5c3d8026711a1eb50b2917b61d59)
The FunctionCallTrace object consumes a few hundred bytes of stack
space, even when tracing is disabled. This was causing stack overflows:
$ nix-instantiate '<nixpkgs> -A texlive.combined.scheme-full --dry-run
error: stack overflow (possible infinite recursion)
This is with the default stack size of 8 MiB.
Putting the object on the heap reduces stack usage to < 5 MiB.
(cherry picked from commit 98ef11677c43db9aa669768d9f0cbec704e8831c)
Rather than having a single function in the Game.Lenses module for
determining what collision type if any an entity has, track it in the
Entity typeclass itself. This is both more extensible and a better
separation of concerns and gets rid of one of the two needs for a
circular import. Yay!
As part of this, I realized nothing was being done to prevent doors from
being placed on tiles that already had walls (since now that was
properly causing a collision!) so I've fixed that as well.
