Skip to content

A
abseil-cpp
Switch branch/tag
  1. 01 Apr, 2023 2 commits
  3. 31 Mar, 2023 3 commits
  5. 30 Mar, 2023 4 commits
  7. 29 Mar, 2023 1 commit
  9. 28 Mar, 2023 1 commit
  11. 27 Mar, 2023 4 commits
  13. 25 Mar, 2023 3 commits
    • type_traits: provide a better fallback for is_trivially_relocatable. · b6a1039b 
      We can do a lot better than always saying "no" on platforms without the
__is_trivially_relocatable builtin. This will allow using this type trait from
the move constructors of InlinedVector in a future CL, without needing to open
code the fallback logic.

PiperOrigin-RevId: 519281125
Change-Id: I0d55f019331966f58074850d6f77c7eab49f2c53
      Abseil Team committed
    • inlined_vector: get rid of IsMemcpyOk. · 32e0395f 
      This type trait had no precise definition, and indeed not even any documentation
at all. Giving the ill-defined concept a name was harmful, because it obscured
several places where the concept was used too conservatively, or even flat-out
incorrectly.

This CL has no behavior change: it simply expands IsMemcpyOk to the same
conditions it previously had. It leaves TODOs for each place where this was too
conservative or incorrect.

PiperOrigin-RevId: 519278325
Change-Id: I25bc89f299f6e40b5c3bce7370ed90f33a95612f
      Abseil Team committed
    • type_traits: touch up the docs for is_trivially_relocatable. · c9f49460 
      Clarify that the trait is conservative: it's safe to act on if it's true, but
false doesn't necessarily mean anything. Of course this is the only reasonable
way to use it, but I think it's helpful to be explicit, especially because
currently this trait *always* returns false on some platforms even for a type
like int.

PiperOrigin-RevId: 519272294
Change-Id: Ic63a48dcf18efc0756046b3d6f51d11cbb46a469
      Abseil Team committed
  15. 24 Mar, 2023 4 commits
  17. 23 Mar, 2023 3 commits
  19. 21 Mar, 2023 2 commits
  21. 20 Mar, 2023 4 commits
  23. 16 Mar, 2023 4 commits
  25. 15 Mar, 2023 4 commits
  27. 14 Mar, 2023 1 commit
    • Synchronization: Add support for true relative timeouts using · 6d41348a 
      monotonic clocks on Linux when the implementation uses futexes

After this change, when synchronization methods that wait are passed
an absl::Duration to limit the wait time, these methods will wait for
that interval, even if the system clock is changed (subject to any
limitations with how CLOCK_MONOTONIC keeps track of time). In other
words, an observer measuring the time with a stop watch will now see
the correct interval, even if the system clock is changed. Previously,
the duration was added to the current time, and methods would wait
until that time was reached on the possibly changed realtime system
clock.

The behavior of the synchronization methods that take an absl::Time is
unchanged.  These methods always wait until the absolute point in time
is reached and respect changes to the system clock. In other words, an
observer will always see the timeout occur when a wall clock reaches
that time, even if the clock is manipulated externally.

Note: ABSL_PREDICT_FALSE was removed from the error case in Futex as
timeouts are handled by this case, and timeouts are part of normal
operation.
PiperOrigin-RevId: 516534869
Change-Id: Ib70b83e4be3f9e3f1727646975a21a1d30acb242
      Derek Mauro committed