[all-commits] [llvm/llvm-project] 56a344: [libcxx] Fix using the vcruntime ABI with _HAS_EXC...

Paul Kirth via All-commits all-commits at lists.llvm.org
Wed Aug 17 14:14:42 PDT 2022

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 56a34451e1cc54375e5fd35d46c7dfba88b32fc5
  Author: Paul Kirth <paulkirth at google.com>
  Date:   2022-08-17 (Wed, 17 Aug 2022)

  Changed paths:
    M libcxx/include/exception
    M libcxx/include/new
    M libcxx/include/typeinfo
    A libcxx/test/configs/llvm-libc++-shared-no-vcruntime-clangcl.cfg.in
    M libcxx/utils/ci/buildkite-pipeline.yml
    M libcxx/utils/ci/run-buildbot

  Log Message:
  [libcxx] Fix using the vcruntime ABI with _HAS_EXCEPTIONS=0 defined

_HAS_EXCEPTIONS=0 allows disabling the exception parts of the MS STL
and vcruntime, and e.g. compiler-rt/lib/fuzzer sets this define (to
work around issues with MS STL). If using libc++ instead of MS STL,
this define previously broke the libc++ headers.

If _HAS_EXCEPTIONS is set to 0, the vcruntime_exception.h header
doesn't define the ABI base class std::exception. If no exceptions
are going to be thrown, this probably is fine (although it also
breaks using subclasses of it as regular objects that aren't thrown),
but it requires ifdeffing out all subclasses of all exception/error
derived objects (which are sprinkled throughout the headers).

Instead, libc++ will supply an ABI compatible definition when
_HAS_EXCEPTIONS is set to 0, which will make the class hierarchies

In this build configuration, one can still create instances of
exception subclasses, and those objects will be ABI incompatible
with the ones from when _HAS_EXCEPTIONS isn't defined to 0 - but
one may argue that's a pathological/self-imposed problem in that case.

Reviewed By: #libc, ldionne

Differential Revision: https://reviews.llvm.org/D103947

More information about the All-commits mailing list