be exported. The one function that is currently using it is easily
implemented with absl::Base64Escape().
PiperOrigin-RevId: 900830658
Change-Id: I859d67efafd5ba96921bb75c9207438975d055d6
Most current uses of ABSL_HARDENING_ASSERT are one of:
* numerical comparison
* checking that a container is non-empty
* checking that a pointer is non-null.
This change adds additional hardening assert functions which conduct the
comparisons necessary for these checks inside the body of the assertion
function, so that the cost of performing the check can be attributed
to the assertion.
For the smaller set of cases where more complex conditions are checked,
a general HardeningAssert which takes a bool is provided.
PiperOrigin-RevId: 899780652
Change-Id: I00602302a5d42d483053ad66d8c3e796d1708567
Most usages of absl::void_t compile fine with std::void_t, so we migrate them here. A few don't compile due to overly eager template instantiations, so we leave those.
PiperOrigin-RevId: 897231619
Change-Id: Iad34101916dac2b995257ebd5d6aacb9a0acfa32
to provide a centralized policy for hardware-accelerated
implementations in headers.
This option addresses ODR violations that occur when Abseil headers
use compile-time feature detection (such as __SSE4_2__) in inline
functions. If translation units are compiled with inconsistent CPU
architecture flags (e.g., -march=native vs -march=generic) and linked
together, they may disagree on the implementation of these inline
functions. This can lead to crashes or silent data corruption in
hashing.
The new option provides three levels of control:
- 0: Portable. Forces software-only implementations in headers,
guaranteeing ABI safety across mixed translation units.
- 1: Required. Forces hardware-accelerated implementations in
headers. The build will fail if the required instructions are not
enabled in the compiler environment.
- 2: Auto-detect. Selects the best available implementation based on
compiler flags, but can't guarantee safety if translation units are
compiled with inconsistent flags.
PiperOrigin-RevId: 896569507
Change-Id: Ifcbc1f3980883feeaa4f05f845ce32310ca7d533
This allows the compiler to optimize conversions to StatusOr since it can
assume the Status is !ok instead of having to check again.
PiperOrigin-RevId: 896110150
Change-Id: I0dc167906b761339aaac5934764fe2bd6deb1624
This won't replace all call sites, but that's fine. We only want to replace the call sites that compile fine, since they don't need to use absl::void_t.
PiperOrigin-RevId: 896017307
Change-Id: I7e78066dc973e135922b11fba5c7642563ef6a67
This will let us deprecate the declarations without triggering warnings in Abseil itself.
PiperOrigin-RevId: 895480358
Change-Id: I2e15877c15ed83f48ddb68cc73344c14b533bc68
This will let us deprecate the declarations without triggering warnings in Abseil itself.
PiperOrigin-RevId: 894202105
Change-Id: I57bb2a1647be1fedf9b724a07042fd0f564ce074
thread_identity by using a void*, and fix callers to use
base::scheduling::Schedulable::GetBoundSchedulable().
PiperOrigin-RevId: 894096577
Change-Id: I2d4c822c60501e34cadcaac7fc434ef9adb222c3
annotations.
This will be used to prevent false positives in the clang-tidy check
bugprone-use-after-move.
PiperOrigin-RevId: 889929118
Change-Id: I19ae27ef20abce9982fbfdcaad4a0aa0fa57f1bd
Consolidate the mocking requirements so that mock detection is mediated
via the MockingAccess class
* HasInvokeMock has been deduplicated; MockingAccess now owns it
* InvokeMock is done via MockingAccess::InvokeMock
* In absl::BitGenRef, if a class has a conversion operator that is used.
* `friend class MockingAccess` is now the only mocking friend, except for backwards compat.
- friend DistributionCaller is now unnecessary.
- friend BitGenRef is now unnecessary.
- friend MockHelpers now unnecessary.
PiperOrigin-RevId: 889366369
Change-Id: I288cd60f6ac13b257c10ec3268d96828f1e61db6
This is intentionally not exposing absl::SourceLocation to Rust yet, since the ownership questions (absl::Status vs. interning etc.) have not yet been decided.
PiperOrigin-RevId: 889297573
Change-Id: I14ed9c1b03c4229bc59e746b49685e87778e6b46
Lambdas are costlier at compile-time and run-time, as they are much heavier machinery and lean much more heavily on the optimizer.
PiperOrigin-RevId: 888814590
Change-Id: I439a36eb6e5ad28fd16675bc254beb315172544c
RecordInsertMiss is where we increment size for hashtablez.
This call was missing, so size was off by one.
We can even end up with negative size if a later erase takes place on the same table.
PiperOrigin-RevId: 882493632
Change-Id: Ifbb58fb2eaa0225d310c919bd0162dc2e0185d58
Currently, when an absl::flat_hash_set or flat_hash_map with SOO (Single Object Optimization) transitions from 0 to 1 element, it queries should_sample_soo() to determine if it should be sampled by hashtablez. If it is NOT sampled, it remains an SOO table. If that element is subsequently erased, the table goes back to 0 elements. The next time it goes from 0 to 1, it queries should_sample_soo() again.
Repeated insert/erase cycles on an SOO table effectively evaluate the sampling logic hundreds of times, making it extremely likely that the table eventually gets sampled and moved to the heap. This causes hashtablez to vastly overstate the memory usage of such maps in production.
This CL fixes this by tracking whether an SOO table has already been evaluated for sampling, so it only evaluates the logic once per table object instance. Since SOO tables do not hash keys, they do not need the per-table generic seed value. This CL utilizes the lowest bit of the unused seed field within HashtableSize (accessed via data_ & 1) to act as a flag soo_has_tried_sampling.
When an SOO table transitions from 0 elements to 1 element, this bit is checked. If it is false, should_sample_soo() is queried and the bit is set to true. set_full_soo() and set_empty_soo() have been modified to preserve the soo_has_tried_sampling bit across erase or clear operations.
PiperOrigin-RevId: 881570273
Change-Id: Ia3b0eff8b3e137b0d162a207220a184923e3a2ca
This makes it possible to make decoration faster by caching some information between runs. Instead of a simple callback a decorator can be a class with a virtual function. This function will not be called concurrently, so it does not need to worry about locking, but it may be called from a signal handler so it must avoid any signal-unsafe operations. The decorator is registered via a factory function, which creates a new object.
Internally, the new decorators are stored inside the ObjFile object and initialized on the first use. If a different factory function is registered, the old decorators are destroyed on the next call to absl::Symbolize.
In order to make the state management simpler, we only support registering a single decorator.
The old interface is left in place to make the migration easier, but it will be removed soon.
PiperOrigin-RevId: 881284709
Change-Id: I25b9db656531fabebd1004f7ec298dc31613b8e3
