[libcxx-commits] [libcxx] [libcxx] Only use `copy_file_range` on Linux or FreeBSD targets (PR #184373)

[Louis Dionne via libcxx-commits]

ldionne wrote:

> Looking at the [uses of `_LIBCPP_HAS_MUSL_LIBC`](https://github.com/search?q=repo%3Allvm%2Fllvm-project+_LIBCPP_HAS_MUSL_LIBC&type=code), it seems like it could mean either "I am using the actual Musl libc" or "My libc's headers are in the same locations as Musl's."

The TLDR here is that any Musl support in the library is vestigial of an earlier port that ended up rotting. We haven't tried ripping it out because I expect this would have caused outcry (and I think this thread confirms it would have), but that port is neither supported nor designed.

If we are to support Trusty and WASI in libc++ (I think we should, and it seems like there is demand for it), I would simply treat them as separate platforms and conditionalize on `__wasi__`, `__TRUSTY__`, etc. It's not clear to me there is even a need for a `_LIBCPP_HAS_MUSL_LIBC`, we probably want to conditionalize on platforms instead of C libraries.

If that turns out to be wrong and we actually want to detect Musl specifically, then we probably should have `_LIBCPP_LIBC_MUSL`, `_LIBCPP_LIBC_<whatever-the-name-of-the-c-library-on-wasi>`, etc. We can also do "Libc inheritance" like having a macro that is true for libcs derived from one, but honestly this usually ends up more confusing than dealing with mutually exclusive choices. We have precedent for libc detection: https://github.com/llvm/llvm-project/blob/5f3b907ed5b63f5dd5ffd03f7509ab29b736d4d9/libcxx/CMakeLists.txt#L821-L830)

https://github.com/llvm/llvm-project/pull/184373