re2 1.24.0 → 1.25.0

package/vendor/abseil-cpp/FAQ.md

@@ -2,9 +2,9 @@
 
 ## Is Abseil the right home for my utility library?
 
-Most often the answer to the question is "no." As both the [About
-Abseil](https://abseil.io/about/) page and our [contributing
-guidelines](https://github.com/abseil/abseil-cpp/blob/master/CONTRIBUTING.md#contribution-guidelines)
+Most often the answer to the question is "no." As both the
+[About Abseil](https://abseil.io/about/) page and our
+[contributing guidelines](https://github.com/abseil/abseil-cpp/blob/master/CONTRIBUTING.md#contribution-guidelines)
 explain, Abseil contains a variety of core C++ library code that is widely used
 at [Google](https://www.google.com/). As such, Abseil's primary purpose is to be
 used as a dependency by Google's open source C++ projects. While we do hope that
@@ -12,27 +12,24 @@ Abseil is also useful to the C++ community at large, this added constraint also
 means that we are unlikely to accept a contribution of utility code that isn't
 already widely used by Google.
 
-## How to I set the C++ dialect used to build Abseil?
+## How do I set the C++ dialect used to build Abseil?
 
 The short answer is that whatever mechanism you choose, you need to make sure
 that you set this option consistently at the global level for your entire
 project. If, for example, you want to set the C++ dialect to C++17, with
-[Bazel](https://bazel/build/) as the build system and `gcc` or `clang` as the
-compiler, there several ways to do this:
-* Pass `--cxxopt=-std=c++17` on the command line (for example, `bazel build
-  --cxxopt=-std=c++17 ...`)
-* Set the environment variable `BAZEL_CXXOPTS` (for example,
-  `BAZEL_CXXOPTS=-std=c++17`)
-* Add `build --cxxopt=-std=c++17` to your [`.bazelrc`
-  file](https://docs.bazel.build/versions/master/guide.html#bazelrc)
+[Bazel](https://bazel.build/) as the build system and `gcc` or `clang` as the
+compiler, there are several ways to do this: * Pass `--cxxopt=-std=c++17` on the
+command line (for example, `bazel build --cxxopt=-std=c++17 ...`) * Set the
+environment variable `BAZEL_CXXOPTS` (for example, `BAZEL_CXXOPTS=-std=c++17`) *
+Add `build --cxxopt=-std=c++17` to your
+[`.bazelrc` file](https://docs.bazel.build/versions/master/guide.html#bazelrc)
 
 If you are using CMake as the build system, you'll need to add a line like
-`set(CMAKE_CXX_STANDARD 17)` to your top level `CMakeLists.txt` file. If you
-are developing a library designed to be used by other clients, you should
-instead leave `CMAKE_CXX_STANDARD` unset and configure the minimum C++ standard
-required by each of your library targets via `target_compile_features`. See the
-[CMake build
-instructions](https://github.com/abseil/abseil-cpp/blob/master/CMake/README.md)
+`set(CMAKE_CXX_STANDARD 17)` to your top level `CMakeLists.txt` file. If you are
+developing a library designed to be used by other clients, you should instead
+leave `CMAKE_CXX_STANDARD` unset and configure the minimum C++ standard required
+by each of your library targets via `target_compile_features`. See the
+[CMake build instructions](https://github.com/abseil/abseil-cpp/blob/master/CMake/README.md)
 for more information.
 
 For a longer answer to this question and to understand why some other approaches
@@ -42,12 +39,12 @@ Abseil?"](#what-is-abi-and-why-dont-you-recommend-using-a-pre-compiled-version-o
 
 ## What is ABI and why don't you recommend using a pre-compiled version of Abseil?
 
-For the purposes of this discussion, you can think of
-[ABI](https://en.wikipedia.org/wiki/Application_binary_interface) as the
-compiled representation of the interfaces in code. This is in contrast to
+For the purposes of this discussion,
+[ABI](https://en.wikipedia.org/wiki/Application_binary_interface) refers to the
+compiled representation of code interfaces. This contrasts with
 [API](https://en.wikipedia.org/wiki/Application_programming_interface), which
-you can think of as the interfaces as defined by the code itself. [Abseil has a
-strong promise of API compatibility, but does not make any promise of ABI
+refers to the interfaces defined in the source code. [Abseil has a strong
+promise of API compatibility, but does not make any promise of ABI
 compatibility](https://abseil.io/about/compatibility). Let's take a look at what
 this means in practice.
 
@@ -72,19 +69,19 @@ program may contain conflicting definitions of the same
 class/function/variable/enum, etc. As a rule, all compile options that affect
 the ABI of a program need to be applied to the entire build on a global basis.
 
-C++ has something called the [One Definition
-Rule](https://en.wikipedia.org/wiki/One_Definition_Rule) (ODR). C++ doesn't
-allow multiple definitions of the same class/function/variable/enum, etc. ODR
-violations sometimes result in linker errors, but linkers do not always catch
-violations. Uncaught ODR violations can result in strange runtime behaviors or
-crashes that can be hard to debug.
+C++ has something called the
+[One Definition Rule](https://en.wikipedia.org/wiki/One_Definition_Rule) (ODR).
+C++ doesn't allow multiple definitions of the same class/function/variable/enum,
+etc. ODR violations sometimes result in linker errors, but linkers do not always
+catch violations. Uncaught ODR violations can result in strange runtime
+behaviors or crashes that can be hard to debug.
 
 If you build the Abseil library and your code using different compile options
 that affect ABI, there is a good chance you will run afoul of the One Definition
 Rule. Examples of GCC compile options that affect ABI include (but aren't
 limited to) language dialect (e.g. `-std=`), optimization level (e.g. `-O2`),
-code generation flags (e.g. `-fexceptions`), and preprocessor defines
-(e.g. `-DNDEBUG`).
+code generation flags (e.g. `-fexceptions`), and preprocessor defines (e.g.
+`-DNDEBUG`).
 
 If you use a pre-compiled version of Abseil, (for example, from your Linux
 distribution package manager or from something like
@@ -98,16 +95,16 @@ all packages have been built with consistent compile options. This is one of the
 reasons we warn against - though do not outright reject - using Abseil as a
 pre-compiled library.
 
-Another possible way that you might afoul of ABI issues is if you accidentally
-include two versions of Abseil in your program. Multiple versions of Abseil can
-end up within the same binary if your program uses the Abseil library and
-another library also transitively depends on Abseil (resulting in what is
-sometimes called the diamond dependency problem). In cases such as this you must
-structure your build so that all libraries use the same version of Abseil.
-[Abseil's strong promise of API compatibility between
-releases](https://abseil.io/about/compatibility) means the latest "HEAD" release
-of Abseil is almost certainly the right choice if you are doing as we recommend
-and building all of your code from source.
+Another possible way that you might run afoul of ABI issues is if you
+accidentally include two versions of Abseil in your program. Multiple versions
+of Abseil can end up within the same binary if your program uses the Abseil
+library and another library also transitively depends on Abseil (resulting in
+what is sometimes called the diamond dependency problem). In cases such as this
+you must structure your build so that all libraries use the same version of
+Abseil.
+[Abseil's strong promise of API compatibility between releases](https://abseil.io/about/compatibility)
+means the latest "HEAD" release of Abseil is almost certainly the right choice
+if you are doing as we recommend and building all of your code from source.
 
 For these reasons we recommend you avoid pre-compiled code and build the Abseil
 library yourself in a consistent manner with the rest of your code.
@@ -121,47 +118,101 @@ to make it compatible. In practice, the need to use an automated tool is
 extremely rare. This means that upgrading from one source release to another
 should be a routine practice that can and should be performed often.
 
-We recommend you update to the [latest commit in the `master` branch of
-Abseil](https://github.com/abseil/abseil-cpp/commits/master) as often as
-possible. Not only will you pick up bug fixes more quickly, but if you have good
-automated testing, you will catch and be able to fix any [Hyrum's
-Law](https://www.hyrumslaw.com/) dependency problems on an incremental basis
-instead of being overwhelmed by them and having difficulty isolating them if you
-wait longer between updates.
-
-If you are using the [Bazel](https://bazel.build/) build system and its
-[external dependencies](https://docs.bazel.build/versions/master/external.html)
-feature, updating the
-[`http_archive`](https://docs.bazel.build/versions/master/repo/http.html#http_archive)
-rule in your
-[`WORKSPACE`](https://docs.bazel.build/versions/master/be/workspace.html) for
-`com_google_abseil` to point to the [latest commit in the `master` branch of
-Abseil](https://github.com/abseil/abseil-cpp/commits/master) is all you need to
-do. For example, on February 11, 2020, the latest commit to the master branch
-was `98eb410c93ad059f9bba1bf43f5bb916fc92a5ea`. To update to this commit, you
-would add the following snippet to your `WORKSPACE` file:
-
-```
-http_archive(
-  name = "com_google_absl",
-  urls = ["https://github.com/abseil/abseil-cpp/archive/98eb410c93ad059f9bba1bf43f5bb916fc92a5ea.zip"],  # 2020-02-11T18:50:53Z
-  strip_prefix = "abseil-cpp-98eb410c93ad059f9bba1bf43f5bb916fc92a5ea",
-  sha256 = "aabf6c57e3834f8dc3873a927f37eaf69975d4b28117fc7427dfb1c661542a87",
+We recommend you update to the
+[latest commit in the `master` branch of Abseil](https://github.com/abseil/abseil-cpp/commits/master)
+as often as possible. Not only will you pick up bug fixes more quickly, but if
+you have good automated testing, you will catch and be able to fix any
+[Hyrum's Law](https://www.hyrumslaw.com/) dependency problems on an incremental
+basis instead of being overwhelmed by them and having difficulty isolating them
+if you wait longer between updates.
+
+If you are using the [Bazel](https://bazel.build/) build system with
+[Bzlmod](https://bazel.build/external/overview#bzlmod), you can use a
+`git_override` in your `MODULE.bazel` file to track the latest commit.
+
+For example, to update to the latest commit, you would add (or update) the
+following snippet in your `MODULE.bazel` file:
+
+```starlark
+bazel_dep(name = "abseil-cpp", version = "20260107.1")
+
+git_override(
+    module_name = "abseil-cpp",
+    remote = "https://github.com/abseil/abseil-cpp.git",
+    # Replace the following line with the latest commit.
+    commit = "6ec9964c325db0610a376b3cb81de073ea6ada90",
 )
 ```
 
-To get the `sha256` of this URL, run `curl -sL --output -
-https://github.com/abseil/abseil-cpp/archive/98eb410c93ad059f9bba1bf43f5bb916fc92a5ea.zip
-| sha256sum -`.
-
-You can commit the updated `WORKSPACE` file to your source control every time
+You can commit the updated `MODULE.bazel` file to your source control every time
 you update, and if you have good automated testing, you might even consider
 automating this.
 
-One thing we don't recommend is using GitHub's `master.zip` files (for example
-[https://github.com/abseil/abseil-cpp/archive/master.zip](https://github.com/abseil/abseil-cpp/archive/master.zip)),
-which are always the latest commit in the `master` branch, to implement live at
-head. Since these `master.zip` URLs are not versioned, you will lose build
-reproducibility. In addition, some build systems, including Bazel, will simply
-cache this file, which means you won't actually be updating to the latest
-release until your cache is cleared or invalidated.
+## Why do I see strange behaviors when I use Abseil hash tables?
+
+Abseil's hash function uses a random seed.
+
+Many programmers believe incorrectly that this is a defense against
+[hash flooding](https://en.wikipedia.org/wiki/Collision_attack#Hash_flooding).
+While it does make a hash flooding attack more difficult, Abseil's hash function
+prioritizes speed over thorough mixing (and thus is not cryptographically
+secure), and the current seed implementation is also not cryptographically
+secure. If you are storing a large amount of attacker-controlled data, the most
+reliable defense against hash-flooding is to use a container that does not have
+`O(n)` worst-case behavior.
+
+The real reason for hash randomization is to prevent
+[Hyrum's Law](https://www.hyrumslaw.com/) dependencies on iteration order. This
+has allowed us to roll out steady improvements to the implementation without
+breaking users who may have otherwise written code that was dependent on
+ordering or other characteristics.
+
+The current implementation uses a global seed, which, if linked incorrectly
+(e.g., static Abseil in multiple DSOs), can cause the ODR violations. If more
+than one seed is linked, different calls to the hash function may return
+different values, rendering hash elements inaccessible, causing crashes, or
+other arbitrarily bad behaviors.
+
+We are often asked for a knob to disable hash randomization. The answer is a
+hard "no", even under test or under a flag, because people will find a way to
+force it and allow their code or tests to depend on it. At Google-scale, the
+compute costs that are saved by preserving the ability to improve the
+implementation far outweigh the inconvenience of learning how to write code
+resilient to change.
+
+## How do I use the LLVM Sanitizers with Abseil?
+
+LLVM Sanitizers are a suite of powerful, dynamic analysis tools that
+automatically detect various critical bugs during program execution. They work
+by instrumenting the compiled binary and linking a runtime library to intercept
+operations and report issues.
+
+We receive many incorrect bug reports from users trying to use the sanitizers.
+The most common cause of these issues is ODR violations in the form of an
+instrumentation mismatch. This happens when users try to link libraries compiled
+with sanitizer instrumentation with uninstrumented libraries. It is important
+that all code in the application is built with the same sanitizer configuration.
+
+The easiest way to do this is to use [Bazel](https://bazel.build) and pass the
+sanitizer options on the commandline, but it is important not to overlook the
+importance of avoiding precompiled system libraries, including the C++ standard
+library. For instance,
+[MemorySanitizer requires an instrumented `libc++`](https://github.com/google/sanitizers/wiki/MemorySanitizerLibcxxHowTo).
+
+Since most users are not going to build `libc++` with Bazel, here is a
+MemorySanitizer recipe that currently works (and could easily be tweaked for
+ThreadSanitizer and friends):
+
+```shell
+# From the root of the LLVM source tree, configure libc++ to be instrumented with MSAN:
+cmake -G Ninja -S runtimes -B build_msan -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX="${HOME}/llvm-msan" -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_USE_SANITIZER=MemoryWithOrigins -DLLVM_TARGETS_TO_BUILD="host"
+
+# Build and install it into ${HOME}/llvm-msan
+ninja -C build_msan install-cxx install-cxxabi install-unwind
+
+# Then build (or test) your code like this:
+bazel test --repo_env=CC=clang --repo_env=BAZEL_CXXOPTS=nostdinc++ --repo_env=BAZEL_LINKOPTS=-L${HOME}/llvm-msan/lib:-lc++:-lc++abi:-lgcc_s:-lm:-Wl,-rpath=${HOME}/llvm-msan/lib --repo_env=CPLUS_INCLUDE_PATH=${HOME}/llvm-msan/include/c++/v1 --copt=-fsanitize=memory --linkopt=-fsanitize=memory --linkopt=-fsanitize-link-c++-runtime ...
+```
+
+You should consider adding these options to a
+[`.bazelrc`](https://bazel.build/run/bazelrc) file to avoid retyping them.

package/vendor/abseil-cpp/MODULE.bazel

@@ -16,8 +16,7 @@
 
 module(
     name = "abseil-cpp",
-    version = "20260107.0",
-    compatibility_level = 1,
+    version = "20260526.0",
 )
 
 cc_configure = use_extension("@rules_cc//cc:extensions.bzl",
@@ -25,13 +24,13 @@ cc_configure = use_extension("@rules_cc//cc:extensions.bzl",
                              dev_dependency = True)
 use_repo(cc_configure, "local_config_cc")
 
-bazel_dep(name = "rules_cc", version = "0.2.9")
-bazel_dep(name = "bazel_skylib", version = "1.8.1")
-bazel_dep(name = "platforms", version = "1.0.0")
+bazel_dep(name = "rules_cc", version = "0.2.18")
+bazel_dep(name = "bazel_skylib", version = "1.9.0")
+bazel_dep(name = "platforms", version = "1.1.0")
 
 bazel_dep(
     name = "google_benchmark",
-    version = "1.9.4",
+    version = "1.9.5",
     dev_dependency = True,
 )
 
@@ -39,5 +38,5 @@ bazel_dep(
 # intended to be used by Abseil users depend on GoogleTest.
 bazel_dep(
     name = "googletest",
-    version = "1.17.0",
+    version = "1.17.0.bcr.2",
 )

package/vendor/abseil-cpp/absl/BUILD.bazel

@@ -60,3 +60,9 @@ selects.config_setting_group(
     ],
     visibility = [":__subpackages__"],
 )
+
+# Expose internals to privileged external repositories.
+package_group(
+    name = "friends",
+    packages = [],
+)

package/vendor/abseil-cpp/absl/algorithm/BUILD.bazel

@@ -41,6 +41,7 @@ cc_library(
     linkopts = ABSL_DEFAULT_LINKOPTS,
     deps = [
         "//absl/base:config",
+        "//absl/base:core_headers",
     ],
 )
 
@@ -69,6 +70,8 @@ cc_library(
         ":algorithm",
         "//absl/base:config",
         "//absl/base:core_headers",
+        "//absl/base:hardening",
+        "//absl/base:iterator_traits_internal",
         "//absl/meta:type_traits",
     ],
 )
@@ -84,6 +87,7 @@ cc_test(
         "//absl/base:config",
         "//absl/base:core_headers",
         "//absl/memory",
+        "//absl/meta:type_traits",
         "//absl/random",
         "//absl/types:span",
         "@googletest//:gtest",

package/vendor/abseil-cpp/absl/algorithm/CMakeLists.txt

@@ -23,6 +23,7 @@ absl_cc_library(
     ${ABSL_DEFAULT_COPTS}
   DEPS
     absl::config
+    absl::core_headers
   PUBLIC
 )
 
@@ -48,7 +49,9 @@ absl_cc_library(
     ${ABSL_DEFAULT_COPTS}
   DEPS
     absl::algorithm
+    absl::hardening
     absl::config
+    absl::iterator_traits_internal
     absl::core_headers
     absl::meta
   PUBLIC
@@ -66,6 +69,7 @@ absl_cc_test(
     absl::config
     absl::core_headers
     absl::memory
+    absl::meta
     absl::random_random
     absl::span
     GTest::gmock_main

package/vendor/abseil-cpp/absl/algorithm/algorithm.h

@@ -27,6 +27,7 @@
 #include <type_traits>
 
 #include "absl/base/config.h"
+#include "absl/base/macros.h"
 
 namespace absl {
 ABSL_NAMESPACE_BEGIN
@@ -40,8 +41,39 @@ ABSL_NAMESPACE_BEGIN
 //
 // See the documentation for the STL <algorithm> header for more information:
 // https://en.cppreference.com/w/cpp/header/algorithm
-using std::equal;
-using std::rotate;
+
+template <class InputIt1, class InputIt2>
+ABSL_DEPRECATE_AND_INLINE()
+constexpr bool equal(InputIt1 first1, InputIt1 last1, InputIt2 first2) {
+  return std::equal(first1, last1, first2);
+}
+
+template <class InputIt1, class InputIt2, class BinaryPredicate>
+ABSL_DEPRECATE_AND_INLINE()
+constexpr bool equal(InputIt1 first1, InputIt1 last1, InputIt2 first2,
+                     BinaryPredicate p) {
+  return std::equal(first1, last1, first2, p);
+}
+
+template <class InputIt1, class InputIt2>
+ABSL_DEPRECATE_AND_INLINE()
+constexpr bool equal(InputIt1 first1, InputIt1 last1, InputIt2 first2,
+                     InputIt2 last2) {
+  return std::equal(first1, last1, first2, last2);
+}
+
+template <class InputIt1, class InputIt2, class BinaryPredicate>
+ABSL_DEPRECATE_AND_INLINE()
+constexpr bool equal(InputIt1 first1, InputIt1 last1, InputIt2 first2,
+                     InputIt2 last2, BinaryPredicate p) {
+  return std::equal(first1, last1, first2, last2, p);
+}
+
+template <class ForwardIt>
+ABSL_DEPRECATE_AND_INLINE()
+constexpr ForwardIt rotate(ForwardIt first, ForwardIt n_first, ForwardIt last) {
+  return std::rotate(first, n_first, last);
+}
 
 // linear_search()
 //