Skip to content

A
abseil-cpp
Switch branch/tag
  1. 25 Apr, 2024 1 commit
  3. 24 Apr, 2024 5 commits
  5. 19 Apr, 2024 1 commit
  7. 18 Apr, 2024 7 commits
  9. 17 Apr, 2024 1 commit
  11. 15 Apr, 2024 1 commit
    • `log/internal/check_op`: Add ABSL_ATTRIBUTE_UNUSED to CHECK macros when STRIP_LOG is enabled · e304ff50 
      When `STRIP_LOG` is off, the internal variable `absl_log_internal_check_op_result` is passed to `absl::log_internal::LogMessageFatal()` and used in the failure message.
When `STRIP_LOG` is on, the variable is truly unused.

Applying a `ABSL_ATTRIBUTE_UNUSED` on the variable triggers `-Wused-but-marked-unused` when `STRIP_LOG` is off, not applying the attribute triggers `-Wunused-but-set-variable` when `STRIP_LOG` is on.

Define a new internal macro `ABSL_LOG_INTERNAL_ATTRIBUTE_UNUSED_IF_STRIP_LOG` that evaluates to `ABSL_ATTRIBUTE_UNUSED` when `STRIP_LOG` is on and nothing when `STRIP_LOG` is off to address both of these scenarios.

PiperOrigin-RevId: 625049155
Change-Id: Ia3f8a6ca916dd67a287bbda4b9bd6c574c92247a
      Dino Radakovic committed
  13. 12 Apr, 2024 1 commit
  15. 09 Apr, 2024 2 commits
  17. 05 Apr, 2024 1 commit
  19. 04 Apr, 2024 4 commits
  21. 03 Apr, 2024 1 commit
  23. 02 Apr, 2024 6 commits
  25. 01 Apr, 2024 1 commit
    • Add internal traits for lifetimebound detection · 8a31d4a8 
      This will helps compilers that understand `ABSL_ATTRIBUTE_LIFETIME_BOUND` flag constructs such as
`absl::StatusOr<std::string_view> str = std::string(...)`
as error-prone.

For standard types, this is done via specializing the type traits.
For all other types, this is done by detecting the presence of a Boolean member trait such as:
`using absl_internal_is_view = std::true_type;`
in the type.

This is purely intended as a safety feature, and the values of these traits (even if wrong!) must NOT be depended on for correct behavior.
Furthermore, only high-value types (such as `absl::StatusOr`) are the intended users here.
Do not declare or use these traits on arbitrary types that are unlikely to be misused.

Do not depend on any of these to be stable, as they not (yet) public APIs.
Moreover, the trait declarations and mechanisms are all subject to change.
(For example, if `[[clang::lifetimebound]]` becomes possible to detect directly, the traits may need to be altered to utilize that, and distinguish between assignments and constructions.)

Should these or similar APIs be made public at a later point, the detection mechanisms may be altered quickly, and may (either loudly or silently) break existing code depending on these internal APIs without notice.

PiperOrigin-RevId: 620868493
Change-Id: I4a528a1dcf0df6ffbc3641d09537bc4c674aee4e
      Abseil Team committed
  27. 29 Mar, 2024 1 commit
  29. 28 Mar, 2024 4 commits
  31. 27 Mar, 2024 3 commits
    • Optimize InsertMiss for tables without kDeleted slots. · 41136ed1 
      This CL contains two optimizations that were measured together.

1) InsertMiss (i. e. successful insert) optimization:
The idea that in case there is no kDeleted, we already know 99% of the information. So we are finding the position to insert with 2 asm instructions (or 3 in case of ARM or portable) and passing that as a hint into `prepare_insert`.

`prepare_insert` is out of the line in order to minimize effect on InsertHit (the most important case). `prepare_insert` may use the hint in case we still have growth and no kDeleted is guaranteed.

In case of kDeleted, we still call `find_first_non_full` in order to potentially find kDeleted slot earlier. We may consider different ways to do it faster for kDeleted later.

2) `find_first_non_full` optimization:

After optimization #1 `find_first_non_full` is used:
1. during resize and copy
2. right after resize
3. during DropDeletedWithoutResize
3. in InsertMiss for tables with kDeleted

In cases 1-3 the table is quite sparse.

1. After resize it is 7/16 sparse
2. During resize it is 7/16 maximum, but during first inserts it is much sparser.
3. During copy it may be up to 7/8, but at the beginning it is way sparser.
4. During DropDeletedWithoutResize it is 25/32 sparse, but at the beginning it is way sparser.

The only case, where the table is not known to be sparse, with `find_first_non_full` usage is a table with deleted elements. But according to hashz, we have <3% such tables. Adding an extra branch wouldn't hurt much there.

PiperOrigin-RevId: 619681885
Change-Id: Id3e2852cc6d85f6c8f90982d7aeb14799696bf39
      Vitaly Goldshteyn committed
    • Use GrowthInfo without applying any optimizations based on it. · 52715dbd 
      PiperOrigin-RevId: 619649335
Change-Id: I8b3380816418a363fb6686db7966248cb530c491
      Vitaly Goldshteyn committed
    • Disable small object optimization while debugging some failing tests. · ff0a0f2d 
      PiperOrigin-RevId: 619598530
Change-Id: Ie4b808a3b826db8c271c81914c7a88d2c6216eb2
      Evan Brown committed