llvm-project

dc53f17c - [asan] Adopt sanitizer_common operator-new framework (#196388)

[asan] Adopt sanitizer_common operator-new framework (#196388) This completes the series that makes AddressSanitizer's `operator new` conform to [new.delete.single]/3-4 (google/sanitizers#295), building on #196413, #200719, #201151, #202816, #213077, #225847, #231994 and #226832. ASan's eight `operator new` overrides now use the shared framework in `sanitizer_new_operators.inc`. On allocation failure they call the current `std::new_handler` until allocation succeeds or the chain is exhausted. After that: - `allocator_may_return_null=0` (default): report out-of-memory and abort once the handler chain is exhausted. Programs that install a `std::new_handler` now see it run first; previously ASan never called it. - `allocator_may_return_null=1`: throwing `new` throws `std::bad_alloc` (aborts if the runtime is built without exceptions, e.g. on Windows); nothrow `new` returns `nullptr`. This resolves the long-standing TODO to throw `std::bad_alloc` instead of dying on OOM. Other changes: - The `asan_new*` helpers pass `may_return_null=true`, so storage failures reach the framework as `nullptr`. - An oversized `operator new` request now reports `out-of-memory` after the handler chain, instead of `allocation-size-too-big`. - Correct the `allocator_may_return_null` description and add a release note. Tests cover all eight overloads. Coverage that applies to any adopting sanitizer is added as sanitizer_common tests rather than ASan-specific ones, gated by a new `operator-new-framework` lit feature that this commit enables for ASan. The existing `allocator_returns_null` and `max_allocation_size` tests use the feature to expect `std::bad_alloc` from adopting tools and an abort from the rest. New ASan tests cover the unaligned nothrow overloads, including on Windows, where sanitizer_common tests do not run. Handler exceptions and the exhaustion policy are covered by the framework unit tests in #226832. Assisted-by: Claude Opus 5.5 --------- Co-authored-by: Vitaly Buka <vitalybuka@google.com>