[libcxx] using has_extension instead of has_feature

Hello,

I'd like to propose to use __has_extension instead of __has_feature to detect available features in libc++ headers.

Using __has_feature prevent usage of functionalities provided by clang as extension when compiling in older standard mode.

As __has_extension is a superset of __has_feature, it should not have any effect on people using the library in c++0x mode.

And when using -pedantic, __has_extension have the same behavior than __has_feature, so it is always be possible to disable extensions if needed.

Path to perform this change (if accepted) attached.

Thanks

-- Jean-Daniel

has_extension.patch (22.1 KB)

Have you tested this thoroughly? While I think this is a good idea, my
experience with it has been that the code doesn't work with certain
combinations of features in a number of places. Not to say that these
aren't bugs (they are), but that we should make sure they are fixed
before we go about making changes to the feature structure.

Sean

Thanks for doing this work. I was previously ignorant of the difference between __has_feature and __has_extension.

I surveyed the differences and found only three where this change would actually impact libc++ (using tags/Apple/clang-211.9):

In C++03 mode the following features are turned on by using __has_extension but not by using __has_feature:

cxx_rvalue_references
cxx_reference_qualified_functions
cxx_deleted_functions

Does clang actually make these features work in C++03? Or is the syntax merely accepted?

Howard

They work in C++03; they normally produce warnings but these are
suppressed due to the system header pragma.

Sean

Hello,

I'd like to propose to use __has_extension instead of __has_feature to detect available features in libc++ headers.

Using __has_feature prevent usage of functionalities provided by clang as extension when compiling in older standard mode.

As __has_extension is a superset of __has_feature, it should not have any effect on people using the library in c++0x mode.

And when using -pedantic, __has_extension have the same behavior than __has_feature, so it is always be possible to disable extensions if needed.

Path to perform this change (if accepted) attached.

Thanks for doing this work. I was previously ignorant of the difference between __has_feature and __has_extension.

I surveyed the differences and found only three where this change would actually impact libc++ (using tags/Apple/clang-211.9):

In C++03 mode the following features are turned on by using __has_extension but not by using __has_feature:

cxx_rvalue_references
cxx_reference_qualified_functions
cxx_deleted_functions

In clang trunk, the HasExtension() method (in Lex/PPMacroExpansion.cpp) defines 5 extensions for C++:

cxx_deleted_functions
cxx_inline_namespaces
cxx_override_control
cxx_reference_qualified_functions
cxx_rvalue_references

Now that I think about it, it may cause problems as if I understand correctly, to properly handle rvalue, you have to support cxx_noexcept too.

Does clang actually make these features work in C++03? Or is the syntax merely accepted?

My understanding was that feature defined as extension are fully available, but I may be wrong.

Howard

-- Jean-Daniel

No, I didn't test it thoroughly, and now that you mention it, I think there is in fact some case where it will cause problems (rvalue support without noexcept support).

Maybe clang should clarify what it defines as language extensions, and what are the pro and cons of using such extension.

-- Jean-Daniel