[all-commits] [llvm/llvm-project] f6a749: [runtimes] Add tests for vendor-specific properties

[Louis Dionne via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f6a74908a7e725cb13769ad12b9202185d87b83b
      https://github.com/llvm/llvm-project/commit/f6a74908a7e725cb13769ad12b9202185d87b83b
  Author: Louis Dionne <ldionne.2 at gmail.com>
  Date:   2021-10-07 (Thu, 07 Oct 2021)

  Changed paths:
    M libcxx/cmake/caches/Apple.cmake
    M libcxx/test/configs/legacy.cfg.in
    A libcxx/test/libcxx/vendor/apple/system-install-properties.sh.cpp
    M libcxx/utils/libcxx/test/config.py
    M libcxx/utils/libcxx/test/params.py
    M libcxxabi/test/lit.site.cfg.in
    A libcxxabi/test/vendor/apple/system-install-properties.sh.cpp
    M libunwind/test/lit.site.cfg.in

  Log Message:
  -----------
  [runtimes] Add tests for vendor-specific properties

Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.

In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.

The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.

But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.

This is a re-application of 9892d1644f, which was reverted in 138dc27186be
because it broke the build. The issue was that we didn't apply the required
changes to libunwind and our CI didn't notice it because we were not
running the libunwind tests. This has been fixed now, and we're running
the libunwind tests in CI now too.

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