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

Set correct flags for clang-cl.
https://github.com/abseil/abseil-cpp/pull/278

clang-cl produce binaries with MSVC ABI and wants to be as
flag-compatible with pure MSVC as possible, so this leads to all sorts
of weird cases.

clang-cl alias /Wall as clang's -Weverything which is way too verbose,
so it needs /W3 like pure MSVC.

clang-cl only understand GCC style warning flags (-W[no]blah) and just
silent drop MSVC style warning flags (/wd[num]).

clang-cl needs MSVC define flags since it is consuming the same header
files as pure MSVC.

CMake set CMAKE_CXX_COMPILER_ID as Clang when clang-cl is detected, so
need extra if (MSVC) to differentiate it.

We are not doing clang-cl specialization in Bazel as currently there
is no reliable way to detect clang-cl in Bazel..

Other changes:
Add ABSL_ prefix to variable names to avoid name collision in CMake.

PiperOrigin-RevId: 239841297

--
add96c3fc067d5c7b6f016d2ba74725a443a185e by CJ Johnson <johnsoncj@google.com>:

Eventually Storage will need to refer to the type `absl::InlinedVector<...>*`. This can be done via a forward declaration. However, doing so would move the defaulted allocator template parameter to the forward declaration and thus inside an internal file. Instead of doing that, this change gives Storage access to the template and it's parameters so the complete type can be formed without including it.

PiperOrigin-RevId: 239811298

--
b5f5279f1b13b09cae5c745597d64ea1efab146b by CJ Johnson <johnsoncj@google.com>:

Simplify/cleanup the benchmark tests for InlinedVector

PiperOrigin-RevId: 239805767

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

Update the internal-only IsSwappable traits to be nested inside of namespace absl so that the script to add inline namespaces for LTS releases works with the implementation.

PiperOrigin-RevId: 239622024

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

Mutex: fix tsan annotations

This fixes 2 bugs:
1. We call cond directly in Mutex::AwaitCommon without using EvalConditionAnnotated. As the result we call into user code ignoring synchronization, miss synchronization and report false positives later. Use EvalConditionAnnotated to call cond as we should.

2. We call Mutex invariant ignoring synchronization. Result is the same: we miss synchronization and report false positive races later. Reuse EvalConditionAnnotated to call mutex invariant too.

PiperOrigin-RevId: 239583878

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

Clarify how to obtain the same behavior as std::unordered_map::erase if need be.

PiperOrigin-RevId: 239549513

--
6e76e68ed084fd1247981dbb92677ce8e563b0ec by Jon Cohen <cohenjon@google.com>:

Avoid the -S -B form of `cmake` since it's only supported starting in CMake 3.13

PiperOrigin-RevId: 239473143
GitOrigin-RevId: 8b7c3bc2fb69608e9b2389b1be0b0de840a4c59d
Change-Id: Ib6d356fa1a7435260273df991e65df4149bd5861