commit aa9a09daf62f45ef4af7d0b679c7059591b72fbb
author Stefan Zager <szager@chromium.org> Tue Feb 07 01:04:49 2023
committer Chromium LUCI CQ <chromium-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue Feb 07 01:04:49 2023
tree 81e899c3cbd9bed79b9f3011218be5909b2711fa
parent 12134186ff2bb8b7eda7355bc713e742c6bfb478

Fix STACK_ALLOCATED usage

STACK_ALLOCATED will be ported to base/ and enforced via new code in
the chromium clang plugin:

https://chromium-review.googlesource.com/c/chromium/src/+/4137572

The new implementation is somewhat stricter than the existing one; in
particular, the existing blink clang plugin does not enforce
STACK_ALLOCATED for types that don't participate in tracing/gc.

This CL fixes the handful of places in the chromium code where the new
implementation currently flags errors. The most significant change is
in WTF hash iterators -- they are marked STACK_ALLOCATED to avoid the
need for Trace() methods, but there are existing cases where iterators
are used in a non-stack-allocated way -- for valid reasons that can't
simply be refactored away -- with hash tables that don't store traceable
values. This patch creates template specializations for the iterator
types so that they will be STACK_ALLOCATED whenever the underlying
hash table stores traceable types.

Examples of persistent iterators can be found in:

blink::EventCountsIterationSource
blink::BluetoothManufacturerDataMapIterationSource
blink::BluetoothServiceDataMapIterationSource
blink::KeyboardLayoutMapIterationSource
blink::StorageAreaMap
blink::GPUSupportedFeatures

Bug: 1409156
Change-Id: I2171d42839de700eed1551969ce721cec30177b7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4225998
Reviewed-by: Steinar H Gunderson <sesse@chromium.org>
Commit-Queue: Stefan Zager <szager@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Code-Coverage: Findit <findit-for-me@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1101895}