__has_feature(cxx_exceptions) returns true but fails to compile std::uncaught_exceptions()

[noloader (Jeffrey Walton)]

I'm testing C++17 on OS X 10.8.5 and 10.9.5 using Macports Clang compiler versions 5.0 and 6.0. Attempting to compile the following program:

$ cat test.cxx
#if __EXCEPTIONS && __has_feature(cxx_exceptions)
# include <exception>
# define CXX17_EXCEPTIONS 1
#endif

void Foo()
{
#if defined(CXX17_EXCEPTIONS)
    if (std::uncaught_exceptions() == 0)
#endif
    {
        int x = 0;
    }
}

Results in:

$ /opt/local/bin/clang++-mp-5.0 -std=gnu++17 test.cxx -c
test.cxx:9:14: error: 'uncaught_exceptions' is unavailable: introduced in macOS 10.12
    if (std::uncaught_exceptions() == 0)
             ^
/opt/local/libexec/llvm-5.0/include/c++/v1/exception:130:63: note:
      'uncaught_exceptions' has been explicitly marked unavailable here
_LIBCPP_FUNC_VIS _LIBCPP_AVAILABILITY_UNCAUGHT_EXCEPTIONS int uncaught_e...

-std=c++17 produces the same error.

According to the LLVM 3.6 release notes (​https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html#the-exceptions-macro), I believe I am using the correct feature test:

To reliably test if C++ exceptions are enabled, use EXCEPTIONS && has_feature(cxx_exceptions), else things won’t work in all versions of Clang in Objective-C++ files.

==========

Upstream issue report at ​https://bugs.llvm.org/show_bug.cgi?id=39631

==========

$ /opt/local/bin/clang++-mp-6.0 --version
clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-6.0/bin

$ /opt/local/bin/clang++-mp-5.0 --version
clang version 5.0.2 (tags/RELEASE_502/final)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-5.0/bin

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.9.5
BuildVersion:   13F1911

I don't know the Macport version and I can't find the method searching ("macport version command line"). "port --version" and "port -V" does not return it.

[mf2k (Frank Schima)]

In the future, please fill in the Port field with the name of the port and add the port maintainer(s) to Cc (port info --maintainers clang-6.0), if any.

[jmroot (Joshua Root)]

Replying to noloader:

According to the LLVM 3.6 release notes (​https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html#the-exceptions-macro), I believe I am using the correct feature test:

To reliably test if C++ exceptions are enabled, use __EXCEPTIONS && __has_feature(cxx_exceptions), else things won’t work in all versions of Clang in Objective-C++ files.

This doesn't say anything about C++17 features, just that it tells you whether C++ exceptions are enabled at all. Since uncaught_exceptions is part of the standard library and not the compiler, I would guess its absence isn't a problem with clang++ as such.

[noloader (Jeffrey Walton)]

Replying to jmroot:

Replying to noloader:

According to the LLVM 3.6 release notes (​https://releases.llvm.org/3.6.0/tools/clang/docs/ReleaseNotes.html#the-exceptions-macro), I believe I am using the correct feature test:

To reliably test if C++ exceptions are enabled, use __EXCEPTIONS && __has_feature(cxx_exceptions), else things won’t work in all versions of Clang in Objective-C++ files.

This doesn't say anything about C++17 features, just that it tells you whether C++ exceptions are enabled at all. Since uncaught_exceptions is part of the standard library and not the compiler, I would guess its absence isn't a problem with clang++ as such.

Thanks Joshua.

Maybe I am parsing something incorrectly, but according to ​C++ feature test macros, __has_feature(cxx_exceptions) is supposed to give me the correct answer:

[feature test macros] provide a set of preprocessor macros which give a simple and portable way to detect the presence of C++ standards and experimental features.

If I understand the concept correctly, then __has_feature(cxx_exceptions) should return false because std::uncaught_exceptions() is not available.

Or maybe I am not understanding the word-smithing that's happening here. As an analogy, are you saying I'm buying a car with a anti-lock brake system but the brakes don't work and the car won't stop? (This kind of reasoning makes no sense to me).

[jmroot (Joshua Root)]

You're asking whether the car has brakes and expecting an answer of yes to mean it has ABS. IOW, this feature test macro does not test for the feature you think it does.

I don't see any mention of __has_feature on the page you linked, but according to it, it looks like __cpp_lib_uncaught_exceptions is what you should be checking.

[jmroot (Joshua Root)]

Replying to jmroot:

I don't see any mention of __has_feature on the page you linked

Which is because this macro is not itself part of any C++ standard. But the clang docs list __has_feature(cxx_exceptions) under C++98 and confirm that it only really tells you that you're not being compiled with -fno-exceptions.

[kencu (Ken)]

I think we can conclude based on this discussion that this is in all likelihood not actually a clang bug, and is not a MacPorts issue at any rate. Closing.