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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
