Looks like it's broken by this patch

clang: /b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm/tools/clang/lib/AST/ExprConstant.cpp:11055: llvm::APSInt clang::Expr::EvaluateKnownConstInt(const clang::ASTContext &, SmallVectorImpl<clang::PartialDiagnosticAt> *) const: Assertion `Result && "Could not evaluate expression"' failed.

Done

renamed classes

If we are going to support this use-case we need a test.

LGTM

LGTM

LGTM

lgtm

LGTM

typo

LGTM

In D54951#1326132, @delcypher wrote:

In D54951#1325854, @vitalybuka wrote:

@cryptoad
I'd like to still land it if possible. I intend to use this in future patches. I removed it from https://reviews.llvm.org/D54904 to simply have less code to review. My intention is to land this and then add the static_assert(...) that I wanted to write original in a future patch.

Then we can review it with dependent patch?
There is probability that dependent patch will be changed during review or other reasons and we stuck with small but unused piece of code.

Okay. I'll merge this patch back into https://reviews.llvm.org/D54904?id=175500

In D54904#1325788, @delcypher wrote:

In D54904#1325056, @vitalybuka wrote:

LGTM
but PrimaryAllocatorASVT is unused here, should we expect patches with PrimaryAllocatorASVT?

@vitalybuka
Yes there will be patches that will use PrimaryAllocatorASVT. However I should note that we actually only need to support the AddressSpaceView template parameter not being LocalAddressSpaceView for ASan and LSan. For the other sanitizer allocators (e.g. TSan) would could have slightly simpler code that just hard codes using LocalAddressSpaceView rather than making it possible at compile time to change this. I didn't do this because I wanted to make the change uniformly to all the sanitizers. If you'd prefer that I make the changes to all the other sanitizers (i.e. not ASan and LSan) in a different way (i.e. hardcode LocalAddressSpaceView) then please let me know and I'll redo this patch.

In D55167#1324855, @joerg wrote:

I don't see why this interceptor needs to know about the internals of struct cdbr or struct cdbw at all. They are fully opaque. All memory accessed by users is explicitly sized as argument to the functions or returned with the size.

@cryptoad
I'd like to still land it if possible. I intend to use this in future patches. I removed it from https://reviews.llvm.org/D54904 to simply have less code to review. My intention is to land this and then add the static_assert(...) that I wanted to write original in a future patch.

I don't see it in D54904

LGTM
but PrimaryAllocatorASVT is unused here, should we expect patches with PrimaryAllocatorASVT?

LGTM

Assume WIP

Assume WIP

LGTM

docs

more doc strings

changed doc string

"use" everywhere for consistency

update

update

Rebase