The code touched here wasn't consistent in its use of const, but
generally used it in a shallow-const fashion where even vending write
access to a block of memory could be done via a const method.
This causes problems when trying to enforce stricter lifetime checks on
writable spans, because either the code gets confused about whether the
accesses are read-only (it tries to look for the constness of the
returned pointers and can't figure out what to do if things don't
match everywhere) or it thinks something unsafe or non-sane is happening
(write access to rvalues makes no sense, for example, but read access
might in the context of a short-lived call).
Instead consistently model deep constness, which is compliant with
Chrome's style rules on const and fixes all these issues. Mostly, this
means changing const members/ref args to non-const ones.
Bug: 372381413
Change-Id: I2735c52fbf0f32b813055cbb46f7c15b09eb025f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5939406
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Fred Shih <ffred@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1373012}
294250dd48