[libcxx-dev] bad_optional_access is now in libc++.dylib on 10.13 -- headers out of date?

[Louis Dionne via libcxx-dev]

Thanks for the heads up. I think the availability markup was too stringent.

commit 7fb40e1569dd66292b647f4501b85517e9247953
Author: Louis Dionne <ldionne at apple.com>
Date:   Tue Jun 9 14:08:55 2020 -0400

    [libc++] Fix too stringent availability markup for bad_optional_access

    The availability markup for bad_optional_access marked it as being added
    in MacOS 10.14 and aligned releases, however it appears to have been added
    in Mac OS 10.13 and aligned releases.

LMK if that fixes your issue.

Louis

> On May 31, 2020, at 01:53, Ken Cunningham via libcxx-dev <libcxx-dev at lists.llvm.org> wrote:
> 
> Hi all,
> 
> On MacPorts we have users with 10.13 systems who want to build c++17-requiring  software like mkvtoolnix, and others.
> 
> This presently fails on these systems due std:optional::value being listed as unavailable in their libcxx:
> 
> 
> currently std::optional::value is marked as unavailable on 10.13 by the __config settings in the libc++ headers:
> 
> #  define _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS                             \
>      __attribute__((availability(macosx,strict,introduced=10.14)))             \
>      __attribute__((availability(ios,strict,introduced=12.0)))                 \
>      __attribute__((availability(tvos,strict,introduced=12.0)))                \
>      __attribute__((availability(watchos,strict,introduced=5.0)))
> however, the symbol seems to have been added to the libc++.dylib on 10.13
> 
> $ nm /usr/lib/libc++.1.dylib | grep optional
> 0000000000014fc6 T __ZNKSt19bad_optional_access4whatEv
> 0000000000014fe8 T __ZNSt12experimental19bad_optional_accessD0Ev
> 0000000000014fde T __ZNSt12experimental19bad_optional_accessD1Ev
> 0000000000014fd4 T __ZNSt12experimental19bad_optional_accessD2Ev
> 0000000000014faa T __ZNSt19bad_optional_accessD0Ev
> 0000000000014fa0 T __ZNSt19bad_optional_accessD1Ev
> 0000000000014f96 T __ZNSt19bad_optional_accessD2Ev
> 0000000000057750 S __ZTINSt12experimental19bad_optional_accessE
> 0000000000057790 S __ZTISt19bad_optional_access
> 0000000000051850 S __ZTSNSt12experimental19bad_optional_accessE
> 0000000000051880 S __ZTSSt19bad_optional_access
> 0000000000057720 S __ZTVNSt12experimental19bad_optional_accessE
> 0000000000057768 S __ZTVSt19bad_optional_access
> 
> $ c++filt  __ZNSt19bad_optional_accessD0Ev
> std::bad_optional_access::~bad_optional_access()
> 
> and simple test apps do link and run (when built with clang-7.0, that is not so rigorous about excluding std::optional::value
> 
> 
> #include <optional>
> #include <iostream>
> 
> struct Foo { int bar; };
> 
> int main() {
>     Foo foo;
>     std::optional<Foo> opt = foo;
>     opt.value().bar = 42;
>     std::cout << opt.value().bar << std::endl;
> }
> 
> 
> I assume this change in libc++.dylib on 10.13 was recently added in some update and just hadn’t percolated through to the llvm source tree, and I was planning to patch the __config headers we install from libcxx-8.0 and libcxx-9.0 with clang-8.0 and clang-9.0 to allow this.
> 
> Is there some other aspect to this issue I might be overlooking?
> 
> Best,
> 
> Ken
> _______________________________________________
> libcxx-dev mailing list
> libcxx-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20200609/46f7ddb1/attachment.html>