Context:

The STL "annotates" the vector and basic_string containers so that ASan will report container-overflow whenever allocated but un-initialized 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: _Disable_ASan_container_annotations_for_allocator<...some allocator type...>.

Testing:

• For the new annotation opt-out feature: a simple test case was added for basic_string and vector respectively
• For the pre-existing annotation feature: a simple 'death test' test case was added for the aforementioned containers respectively as well. In the case of basic_string, this replaces the recently added test_gh_5251 test (from ASan should detect writing to a basic_string's reserved but uninitialized memory #5252) to avoid repetition.