Revert "Reland "[infra] Update Linux machines to use Clang 15.0.1""
This reverts commit 8704bb831d56f63158cfe420004e8d22c70b6c8d.
Reason for revert: Windows ASAN build issue, Wuffs (ASAN) NPE, and Windows+Angle crash
Original change's description:
> Reland "[infra] Update Linux machines to use Clang 15.0.1"
>
> This is a reland of commit 946da5eda4332e5cbcd73f6b4823be93db4919d8
>
> Original change's description:
> > [infra] Update Linux machines to use Clang 15.0.1
> >
> > The previous version was Clang 10. This only impacts our GN builds
> > (Bazel toolchain will need an update as well as a bit of
> > infrastructure to upload the compiled toolchain).
> >
> > We need to compile Clang from source for two reasons:
> > - https://github.com/llvm/llvm-project/releases/tag/llvmorg-15.0.1
> > does not have pre-built amd64 Linux binaries (v14 was
> > the last one, it seems).
> > - We need to compile libcxx and libcxxabi for MSAN and TSAN
> > to work properly [1] [2]
> >
> > This change compiles Clang using Docker for two reasons:
> > - Docker is more reproducible, which is easier to use and
> > lets us have better SLSA compliance.
> > - Our current Linux compile and test machines are running
> > Debian 10, which has libc version 2.28. If a dev (e.g. me)
> > compiled Clang on a newer version of Debian, it would
> > require a newer version of libc to be on the build machines,
> > which is non-trivial to accommodate.
> >
> > Getting the Docker build to work was a bit tricky, but the
> > official Clang project has a Dockerfile [3] that I cribbed from.
> >
> > Building libcxx and libcxxabi in a non-deprecated way required
> > small, subtle changes [4][5]
> >
> > We no longer add tools/xsan.supp to the include path because
> > Clang warns about "unrecognized pragmas", which is what it thinks
> > the suppression comments are. I think this originally had been
> > added to force re-compilation if the suppression changed (otherwise
> > ninja has no way to know something changed). In Bazel, this would
> > not be an issue (as toolchain contents are accounted for when
> > deciding to rebuild). For our GN builds, the risk is tolerable
> > given how infrequently we update that suppression file.
> >
> > We no longer compile the clang binaries in MinSizeRel mode.
> > I wasn't able to tell via git history why that was chosen in the
> > first place, but we have plenty of bandwidth and disk space on
> > our CI machines; time (i.e. execution time) is the precious
> > resource.
> >
> > [1] https://github.com/google/sanitizers/wiki/MemorySanitizer#using-instrumented-libraries
> > [2] https://github.com/llvm/llvm-project/blob/76fd4bf675b5ceeeca0e4e15cf15d89c7acf4947/llvm/utils/docker/debian10/Dockerfile
> > [3] https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual#non-instrumented-code
> > [4] https://libcxx.llvm.org/BuildingLibcxx.html
> > [5] https://stackoverflow.com/a/73827100/1447621
> >
> > Change-Id: I5c3c6c9bc61fa3c335647a2ff5b0abe259b0bbbb
> > Reviewed-on: https://skia-review.googlesource.com/c/skia/+/583776
> > Reviewed-by: Ravi Mistry <rmistry@google.com>
> > Reviewed-by: Brian Osman <brianosman@google.com>
>
> Change-Id: I561fa5986e7dec72f24c27e4af0799efb6ad881d
> Reviewed-on: https://skia-review.googlesource.com/c/skia/+/584918
> Commit-Queue: Kevin Lubick <kjlubick@google.com>
> Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I8f6add620f3d1ff69060f00ab14523ee86a393b2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/590176
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Kevin Lubick <kjlubick@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
22 files changed
