std::optional::value
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: std::optional::value
- From: Stephan Bergmann <sbergman@xxxxxxxxxx>
- Date: Thu, 13 Jan 2022 09:23:58 +0100
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0
There is an issue with some C++17 functionality that throws certain
exceptions, most prominent apparently being std::optional::value: On
macOS, this functionality is only available in the system libc++
starting with macOS 10.13. That would match our recent baseline (see
<https://git.libreoffice.org/core/+/3e94991d7fd3a085549c3a5d4c991688042d2cb9%5E!/>
"Bump minimum macOS to 10.13"). But versions of LLVM prior to LLVM 11
made a mistake and, in the libc++ include files, labelled that
functionality as only available starting with macOS 10.14 (see
<https://github.com/llvm/llvm-project/commit/7fb40e1569dd66292b647f4501b85517e9247953>
"[libc++] Fix too stringent availability markup for
bad_optional_access"). That means that, even though everything should
work fine at runtime, compiling a use of such functionality with Xcode <
12.5 would fail (see
<https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_-_13.x_(since_SwiftUI_framework)_2>).
(And that is apparently what happened for
<https://gerrit.libreoffice.org/c/core/+/128308> "do not force pixel
reading in VclCanvasBitmap ctor", where
<https://ci.libreoffice.org/job/gerrit_mac/110583/> successfully built
that change---introducing uses of std::optional::value---on tb86 with
Xcode 13.2.1, but later builds of unrelated changes started to fail,
like <https://ci.libreoffice.org/job/gerrit_mac/110609/> on tb69 with
Xcode 11.3.1.) One option would apparently be to limit LO to building
with Xcode >= 12.5, but some hardware (like my early 2013 15" Retina
MacBook Pro) is stuck with macOS 10.15 and thus with Xcode 12.4 (see
<https://en.wikipedia.org/wiki/Xcode#Xcode_11.x_-_13.x_(since_SwiftUI_framework)>).
(For me personally that wouldn't be much of a problem, as I usually
built against a trunk LLVM libc++ on that machine. But it would
presumably be an issue at least for some of the Jenkins machines?) It
would apparently also be useful if all Jenkins Gerrit builders used the
same version of Xcode (ideally the baseline version, so Gerrit changes
introducing uses of the problematic functionality would reliably fail in
Jenkins as long as our baseline is Xcode 11.3), but as that is
presumably not feasible, we need to continue to watch out for this
gotcha as long as we don't bump our Xcode baseline.
[Index of Archives]
[LARTC]
[Bugtraq]
[Yosemite Forum]
[Photo]