Based on discussions at the WG21 meeting in Albuquerque and follow-up email discussions, I believe the correct approach to exposing attributes from Clang is to provide them with GNU-style attribute spellings as well as C++-style [] spellings in the clang vendor namespace, when appropriate. If the attribute was originally provided by a different vendor, and Clang intends to be compatible with those semantics, then the attribute should only be provided with the spellings supported by the original vendor. Otherwise, any attributes provided only by Clang should be exposed as both a GNU-style and C++-style attribute as appropriate for the semantics of that attribute.
To that end, this patch adds a C++ spelling in the clang vendor namespace to a number of attributes. Similarly, it adds a GNU spelling to the lto_visibility_public attribute (which was the only one with a C++ spelling but not a GNU spelling).
Finally, it leaves the following attributes with only a GNU spelling, based on the given rationale:
align_value -- originally provided by Intel with only a GNU spelling
constant, cudart_builtin, device, device_builtin_surface_type, device_builtin_texture_type, host, launch_bounds, shared, nv_weak -- attributes specified by CUDA with only a GNU spelling (several are also ignored attributes)
opencl_unroll_hint, intel_reqd_sub_group_size, nosvm, ext_vector_type, reqd_work_group_size, work_group_size_hint, vec_type_hint -- attributes specified by OpenCL with only a GNU spelling
kernel -- specified by RenderScript
carries_dependency -- supported as a standards-based attribute, shouldn't be in a vendor namespace
enable_if, diagnose_if, guarded_by, pt_guarded_by, acquired_after, acquired_before, assert_exclusive_lock, assert_shared_lock, exclusive_trylock_function, shared_trylock_function, lock_returned, locks_excluded -- not easily used with the C++ spelling because the attribute requires naming function parameters (these might be good candidates to explore changing into type attributes in the future).
bounded -- currently ignored
*Please double-check my understanding of these attribute spellings.* It is possible that I've misunderstood attributes as being specified by other sources when in fact they are Clang extensions, or that something is listed as a Clang extension but is actually a compatibility attribute. If my understanding is correct, I'll add the rationales to Attr.td as comments alongside the attribute spelling so that we don't lose that information.
Because this is a mechanical change that only introduces new spellings, there are no proposed test cases for the patch.