Opened 6 years ago

Closed 6 years ago

#57578 closed defect (invalid)

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

Reported by: noloader (Jeffrey Walton) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: larryv (Lawrence Velázquez)
Port: clang-6.0

Description (last modified by 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.

Change History (10)

comment:1 Changed 6 years ago by noloader (Jeffrey Walton)

Description: modified (diff)

comment:2 Changed 6 years ago by noloader (Jeffrey Walton)

Description: modified (diff)

comment:3 Changed 6 years ago by noloader (Jeffrey Walton)

Description: modified (diff)

comment:4 Changed 6 years ago by 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.

comment:5 Changed 6 years ago by mf2k (Frank Schima)

Cc: larryv added
Keywords: C++17 cxx_exceptions std::uncaught_exceptions() removed
Owner: set to jeremyhu
Port: clang-6.0 added; clang++-mp-6.0 removed
Status: newassigned

comment:6 in reply to:  description ; Changed 6 years ago by 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.

comment:7 in reply to:  6 Changed 6 years ago by 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).

comment:8 Changed 6 years ago by 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.

comment:9 in reply to:  8 Changed 6 years ago by 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.

comment:10 Changed 6 years ago by kencu (Ken)

Resolution: invalid
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.