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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman 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
----------------
philnik wrote:
> 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".
> 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?).

Okay, I think that makes sense to me. Clang has feature test macros for some C functionality (e.g., `c_generic_selections`, more full list at: https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/Features.def#L241)

> 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.

Sold!


================
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
----------------
philnik wrote:
> 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?
> I actually had no idea they existed (might be worth documenting :P)! 

Right? https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-fdouble-square-bracket-attributes exists but is hardly ideal.

> 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++).

It's a bit of an odd situation. I added the feature flag because I wanted to expose this functionality in C before WG14 adopted the functionality and it wasn't entirely clear whether I would run into ambiguities with Objective-C's message sending syntax. C++ has this language rule: http://eel.is/c++draft/dcl.dcl#dcl.attr.grammar-7  but Objective-C allows for things like `[[foo bar] baz];`. We had already solved this for C++, but it wasn't entirely clear whether we'd hit other situations in older language modes or different situations.

These days, it may be possible we could enable this extension by default in all language modes.

> Anyways, we could add another column "flags required" for these cases. Do you know how many of these kinds of flags there are?

I can't think of many... Features.def lists the language options required for various features and extensions, and it doesn't look like many have specific flags, though there are some that needs a more general flag like `-fms-extensions`. We do have things like `-fno-rtti` disabling RTTI, but I don't think we want to list that sort of thing here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D150321