It seems some of the tests are running with /std:c++latest and using the deprecated member functions.
I'd like your input on what to do regarding these tests.

I have two options in mind:

• Run these tests using /std:c++17 flag.
• Adjust them to use std::allocator_trait if _HAS_CXX20.

It seems some of the tests are running with /std:c++latest and using the deprecated member functions.
I'd like your input on what to do regarding these tests.

What we usually do is:

• If the test doesn't "need" to use the deprecated machinery and can be changed to use modern machinery unconditionally, do so.
  • std::allocator_traits is always available, so this would make sense for a test that wasn't specifically concerned with exercising old allocator members.
• If the test doesn't "need" to use the deprecated machinery, but the modern machinery only exists in newer language modes, it would be reasonable to #if _HAS_CXXversion in the test, if it isn't too much trouble.
  • Could apply in a hypothetical world where we deprecated/removed std::remove_if in favor of std::erase_if, not that that will ever happen.
• If the test "needs" to use the deprecated machinery (i.e. it is specifically testing it), define the restore/warning-suppression macros in that test.
  • For example, tr1/tests/memory1 restores shared_ptr::unique and disables its deprecation:
    

    STL/tests/tr1/tests/memory1/test.cpp

    Lines 8 to 9 in b1fbbdc

    	#define _HAS_DEPRECATED_SHARED_PTR_UNIQUE 1
    	#define _SILENCE_CXX17_SHARED_PTR_UNIQUE_DEPRECATION_WARNING

In general, deprecated/removed machinery shouldn't cause us to stop running a test in /std:c++latest mode (the option you mentioned of "Run these tests using /std:c++17 flag."), as that would limit our test coverage. The exception would be if a test is only for deprecated/removed machinery. In that case, it would probably be easiest to just guard the entire test to do nothing in newer language modes, as we don't have "matrix" files that exercise only older language modes (whereas we do have matrices for newer language modes, like usual_latest_matrix.lst).

Looking at the very first test failure, for example:

Here, the test is exercising both deprecated machinery (the offending alloc.construct call) and modern machinery (the allocator_traits<allocator<int>>::construct call), looking for a specific issue (as opposed to using deprecated machinery to achieve something else). We've already suppressed the deprecation warning at the top, so it would be simplest to also define the
"restore machinery" macro. (Alternatively, just the lines testing deprecated machinery could be guarded with #if !_HAS_CXX20, which would be more localized in the sense that the rest of the test couldn't accidentally use the deprecated/removed tech; it's a judgement call and I'd be fine with either, really.)

I would like to note that @BillyONeal had some reservations about removing allocator<void>.

That is why I dropped it from the patch

@StephanTLavavej I decided to define the restore machinery macro because the three failing tests are testing the removed functions as it seems and to be consistent with the other tests in the system. The PR should be ready for review now 😄.

@miscco The current working draft and WG21-P0619 do not include the std::allocator<void> specialization therefore I removed it along with std::allocator's deprecated members. Also, I had a look at GH-380 now and I agree that std::allocator<void>'s presence is unobservable. I can drop that part from the PR if it's the better option 👀.

@miscco The current working draft and WG21-P0619 do not include the std::allocator<void> specialization therefore I removed it along with std::allocator's deprecated members. Also, I had a look at GH-380 now and I agree that std::allocator<void>'s presence is unobservable. I can drop that part from the PR if it's the better option 👀.

allocator<void> was removed from the WP because it needed to exist due to ill-formed-for-void things in the primary template, which were removed from the WP. However, we still provide those removed things because we support older language modes, so we still need an extra specialization so that allocator<void> can be named and all its members are accessible.

Thanks for encouraging code modernization! This will ship in VS 2019 16.10 Preview 1. 🚀 😺