[PATCH] D150321: [clang] Document extensions from later standards

[Nikolas Klauser via Phabricator via cfe-commits]

philnik added inline comments.


================
Comment at: clang/docs/LanguageExtensions.rst:1386
+Relaxed constexpr                   __cpp_constexpr                  C++14         C++11
+Designated initializers             __cpp_designated_initializers    C++20         C++03
+Attributes on enums                 __cpp_enumerator_attributes      C++17         C++11
----------------
aaron.ballman wrote:
> This brings up a few questions for me: how should we handle C? For example, designated initializers also exist in C99 and are backported to C89? And how should we handle C features extended into C++ (or vice versa)?
> 
> Should we have multiple tables? Should we try to put both languages into one table with different columns?
> 
> (I'm not asking you to sign up to figure out the C extensions, just trying to get an idea for whether we want to change the layout of this table to account for that sort of thing.)
I think it would make sense to put C features that are back-ported into previous standards also into this table (are there FTMs for C?). C into C++ or vice versa should probably live somewhere else, since in these cases it would also be interesting how things interact with other language features. Maybe this is not as much of a problem for C++->C(?), but definitely for C->C++. e.g. `__restrict` on member functions or VLAs with non-trivial classes. Essentially, there is a lot more to say than "this also exists in previous standards".


================
Comment at: clang/docs/LanguageExtensions.rst:1387
+Designated initializers             __cpp_designated_initializers    C++20         C++03
+Attributes on enums                 __cpp_enumerator_attributes      C++17         C++11
+Guaranteed copy elision             __cpp_guaranteed_copy_elision    C++17         C++03
----------------
aaron.ballman wrote:
> What are your thoughts on extensions enabled by a feature flag? e.g., https://godbolt.org/z/ex9K5dzv6
I actually had no idea they existed (might be worth documenting :P)! Specifically for this case: Is there any reason this is behind a feature flag? I guess it's a non-conforming extension? If not, I'd say just make it an enabled-by-default extension (it would be a really nice cleanup opportunity for libc++). Anyways, we could add another column "flags required" for these cases. Do you know how many of these kinds of flags there are?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150321/new/

https://reviews.llvm.org/D150321