[all-commits] [llvm/llvm-project] 0f34f1: Merging r367981:

[Fangrui Song via All-commits]

  Branch: refs/heads/release/9.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 0f34f1b9318e7773fd838b9e0b24f0400616540f
      https://github.com/llvm/llvm-project/commit/0f34f1b9318e7773fd838b9e0b24f0400616540f
  Author: Fangrui Song <maskray at google.com>
  Date:   2019-11-19 (Tue, 19 Nov 2019)

  Changed paths:
    M clang/lib/Driver/ToolChains/Linux.cpp
    A clang/test/Driver/linux-musl-header-search.cpp

  Log Message:
  -----------
  Merging r367981:

------------------------------------------------------------------------
r367981 | maskray | 2019-08-05 23:25:32 -0700 (Mon, 05 Aug 2019) | 27 lines

[Driver] Prioritize SYSROOT/usr/include over RESOURCE_DIR/include on linux-musl

On a musl-based Linux distribution, stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h are expected to be provided by musl (/usr/include), instead of RESOURCE_DIR/include.
Reorder RESOURCE_DIR/include to fix the search order problem.
(Currently musl doesn't provide stdatomic.h. stdatomic.h is still found in RESOURCE_DIR/include.)

gcc on musl has a similar search order:

```
 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0
 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/x86_64-alpine-linux-musl
 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/backward
 /usr/local/include
 /usr/include/fortify
 /usr/include
 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/include
```

This is different from a glibc-based distribution where RESOURCE_DIR/include is placed before SYSROOT/usr/include.

According to the maintainer of musl:

> musl does not support use/mixing of compiler-provided std headers with its headers, and intentionally has no mechanism for communicating with such headers as to which types have already been defined or still need to be defined. If the current include order, with clang's headers before the libc ones, works in some situations, it's only by accident.

Reviewed by: phosek

Differential Revision: https://reviews.llvm.org/D65699
------------------------------------------------------------------------