Add per-allocator disablement of ASan

[davidmrdavid]

Please note this PR is blocked on: #5251

Context:

The STL "annotates" the vector and basic_string containers so that ASan will fire an error whenever allocated but initialized container data is accessed. A simple repro is the container overflow error fired in this sample program (assuming it's /fsanitize=address'ed):

// Compile with: cl /EHsc /fsanitize=address /Zi
#include <vector>

int main() {   
    std::vector<int> v(10);
    v.reserve(20); // we've allocated 20 entries, but only initialized only 10

    // Accessing the 10th entry (0-indexed, naturally) triggers an AV 
    v[10] = 1;

}

This is sensible behavior in most cases.

One case where it does not bode well is when an arena allocator is used as the custom allocator of the container. Arena allocators often tamper with the entire allocated memory at once (e.g. they commonly deallocate their entire 'arena' at once) which would trigger ASan AVs when the capacity of the container exceeds it's size.

We encountered one such bug in the msvc front end.

This PR:

This PR introduces the ability for custom allocators to opt-out of vector and basic_string's ASan annotations. This is controlled by the newly introduced template variable: _Is_ASan_enabled_for_allocator<...some allocator type...>.

A simple test for the vector and basic_string container cases was added as well.

Ask for reviewers:

• I've left some TODO and FIXME comments in the diff, those are pending and I'd appreciate guidance on those. I'll mark the PR as "ready to review" to get visibility on those. I hope that's appropriate, let me know if not.

Why not provide better support for arena allocators instead of opting out?

This opt-out feature does not replace the need to additionally provide better support for arena-type allocators (and other exceptional cases) in our STL ASan annotations. This is just meant to be a simple 'catch-all' workaround for those cases but is not the ideal afaict. I'm hoping to push for a more principled long-term solution for the msvc FE ASan bug, but this just a "band aid fix" for now.

[CaseyCarter]

This is probably due to IntelliSense picking up the installed STL headers instead of the headers in your STL repo.

[davidmrdavid]

Oh, that makes sense. I'll remove this comment in my next commit then.

Just curious - do we have a good way of teling intellisense about this, or do we just 'ignore' the false alarm?

[StephanTLavavej]

We test IntelliSense via the /BE command-line option. That should pick up your freshly built STL headers.

As for actual IntelliSense in the IDE, no idea. I would expect that if you've built something with the freshly built STL picked up (remember set_environment.bat!), then it would know the correct paths.

[davidmrdavid]

I'll do some digging and find out, would be good to document :-) . Thanks!

[davidmrdavid]

Marking as draft for now to try and simplify the test.
Update 1/24: Keeping as draft until #5251 is resolved.

[zacklj89]

Nice!

I may have missed some conversation about it, but I'm wondering if the name should be changed. The feature is disabling annotations based on the container's underlying allocator.

Since the options for compiler are _DISABLE_X_ANNOTATION should we try to follow suite with Disable in the name?

[davidmrdavid]

Since the options for compiler are _DISABLE_X_ANNOTATION should we try to follow suite with Disable in the name?

Oh I didn't realize the compiler options / flags followed that naming convention? Do you have a link or example where I can see this?

But yeah, don't feel strongly about naming. If it matches the flags, I'm happy to have Disabled over Enabled in the name. I'll tackle that on my next push.

[zacklj89]

Yeah, I'm basically commenting on staying in line with these

[davidmrdavid]

Incorporated: 57e7aff