Finish Fixing Atomic Initialization

[AdamBucior]

Description

Resolves #336. The only problem is that I don't know how to signal deprecation of ATOMIC_VAR_INIT and ATOMIC_FLAG_INIT macros.

Checklist

Be sure you've read README.md and understand the scope of this repo.

If you're unsure about a box, leave it unchecked. A maintainer will help you.

• Identifiers in product code changes are properly _Ugly as per
  https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
• The STL builds successfully and all tests have passed (must be manually
  verified by an STL maintainer before automated testing is enabled on GitHub,
  leave this unchecked for initial submission).
• These changes introduce no known ABI breaks (adding members, renaming
  members, adding virtual functions, changing whether a type is an aggregate
  or trivially copyable, etc.).
• These changes were written from scratch using only this repository,
  the C++ Working Draft (including any cited standards), other WG21 papers
  (excluding reference implementations outside of proposed standard wording),
  and LWG issues as reference material. If they were derived from a project
  that's already listed in NOTICE.txt, that's fine, but please mention it.
  If they were derived from any other project (including Boost and libc++,
  which are not yet listed in NOTICE.txt), you must mention it here,
  so we can determine whether the license is compatible and what else needs
  to be done.

[codicodi]

You can generate a message on macro use like this:

#define HELLO_DEPRECATION_WARNING __pragma(message ("Warning: HELLO is deprecated"))
#define HELLO HELLO_DEPRECATION_WARNING "Hello"

It doesn't count as a warning from compiler's perspective though (doesn't turn into error with /WX or -Werror).

[sylveon]

You can use a type to differentiate the use of the ATOMIC_*_INIT operators/constructors, and then deprecate those: https://godbolt.org/z/anYSGd

[CaseyCarter]

We need to ensure that test coverage is similarly made unconditional (we currently have Clang-only test coverage). Perhaps more importantly, we need a test to validate that C1XX correctly constant-initializes at least atomic<int>, atomic<bytes<3>>, atomic<bytes<23>>, and atomic_flag.

(I'm personally not disturbed by the inability to annotate the macros as deprecated.)

[BillyONeal]

I agree we don't need to bend over backwards to mark the macro as deprecated.

[BillyONeal]

@CaseyCarter AFAIK the compiler that ships with 2019 16.5 Preview 2 should have that fixed, so I think we can merge this as soon as that ships.

[StephanTLavavej]

This looks great to me! While I'm the staunchest advocate of emitting deprecation warnings, I believe that attempting to do so for the macros would be more trouble than it's worth.

Merging should wait for VS 2019 16.5 Preview 2's release due to the compiler bugfix dependency.

[BillyONeal]

Internal tests passed. Will merge as soon as 2019 16.5 Preview 2 is available.

[BillyONeal]

Thanks for your contribution!