[all-commits] [llvm/llvm-project] 8cedff: [libc++] Diagnose when header search paths are set...

[Louis Dionne via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8cedff10a18d8eba9190a645626fa6a509c1f139
      https://github.com/llvm/llvm-project/commit/8cedff10a18d8eba9190a645626fa6a509c1f139
  Author: Louis Dionne <ldionne.2 at gmail.com>
  Date:   2022-08-17 (Wed, 17 Aug 2022)

  Changed paths:
    M libcxx/include/cctype
    M libcxx/include/cerrno
    M libcxx/include/cfenv
    M libcxx/include/cfloat
    M libcxx/include/cinttypes
    M libcxx/include/climits
    M libcxx/include/clocale
    M libcxx/include/cmath
    M libcxx/include/csetjmp
    M libcxx/include/cstddef
    M libcxx/include/cstdint
    M libcxx/include/cstdio
    M libcxx/include/cstdlib
    M libcxx/include/cstring
    M libcxx/include/cuchar
    M libcxx/include/cwchar
    M libcxx/include/cwctype

  Log Message:
  -----------
  [libc++] Diagnose when header search paths are set up incorrectly

An issue I often see in codebases compiled for unusual platforms is
that header search paths are specified manually and are subtly wrong.
For example, people will manually add `-isystem <some-toolchain>/usr/include`,
which ends up messing up the layering of header search paths required by
libc++ (because the C Standard Library now appears *before* libc++ in
the search paths). Without this patch, this will end up causing
compilation errors that are pretty inscrutable. This patch aims to
improve the user experience by diagnosing this issue explicitly.

In all cases I can think of, I would expect that a compilation error
occur if these header search paths are not layered properly. This
should only provide an explicit diagnostic instead of failing due
to seemingly unrelated compilation errors.

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