Thanks for pointing them out.

LGTM, but please wait @phosek to approve it.

In D144603#4162223, @phosek wrote:

I agree, in that case let's remove C_COMPILER_LAUNCHER;CXX_COMPILER_LAUNCHER from the list of default passthrough variables which seems like a reasonable default, and provide CLANG_BOOTSTRAP_EXTRA_PASSTHROUGH so developers have a way to pass these through to the next stage if they want to.

In D144603#4162048, @smeenai wrote:

Hmm, what cache key does ccache use for compilers? Is it the --version output string, the path, or some combination? If the path is involved then I don't see any value in using ccache for configuring anything past stage1, since the compiler will (presumably) be installed somewhere else afterwards and not used directly from the build tree. If it's just --version, what are the cache pollution concerns? The compiler binaries output by all the stages should produce the same outputs given the same inputs (and presumably have the same --version), right?

We are seeing a linker error on Mac builder today when we try to roll the clang toolchain for Flutter, error message (build task: https://ci.chromium.org/ui/p/flutter/builders/try/Mac%20Unopt/25679/overview):

I am seeing test failures on pre submit Windows builder after this change was landed: See https://buildkite.com/llvm-project/premerge-checks/builds/135752#01864d34-9024-4c13-9137-88b6f41ec695

There are also cases that this clang type-limit check will warn when checking if a enum type is larger than 0. For example, we are seeing warnings on ICU source code (https://github.com/unicode-org/icu/blob/8d5a97ae0f49f6974372736ca67db15c37522f6f/icu4c/source/i18n/displayoptions.cpp#L79) after this patch was landed.

LGTM. Please wait for the approval from @yln .

FYI, this patch looks like was pushed into a new "Main" branch instead of the actual "main" branch.:

Correct dependency issues on llvm-mt

Thanks for the review. I will land the change once Fuchsia clang builders are green.

Correct an issue llvm-rc and llvm-mt are not part of TOOLCHAIN_TOOLS

Correct C, CXX flag issue.

In D137473#3993584, @bnbarham wrote:

LGTM. If you could put up a PR after to fix the use of sys::fs::make_absolute that would be appreciated 🙇.

Wondering what is the error you see when uses UTC? While there are some differences, UTC and GMT basically means the same thing. So I am really surprised one works fine while the other will fail.

In D139980#3995526, @pzheng wrote:

Thanks for acting upon this quickly, @thakis!

Sorry for the inconveniences caused by this change, @haowei. Do you mind trying the other form of the command (touch -d "1970-01-01T00:00:16Z") on your builder and see if that works? I am hoping that we can have a simple workaround for the container issue I encountered without breaking any other stuff of course.

This change breaks lld/test/MachO/stabs.s on Fuchsia's Mac x64 Clang builder:

I tried again with

cmake -G Ninja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS="clang;lld" -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;compiler-rt" ../llvm -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DLLVM_TARGETS_TO_BUILD="X86"

Rebased the change to solve the merge conflicts on the bots.

I changed some comments and add more details.
If there is no objection, can I get an approval on this change so I can land it? It will unblock our development on Windows cross compilation support.

So I tried

What is your cmake command line when you test the code (when all Profile-x86_64 tests passes)?

We are seeing following test failures on Fuchsia's Clang Linux x64 builders after this change (255c3e3dcb06299aa2365f70817322a8a381c351) landed:

MemorySanitizer-Unit :: ./Msan-x86_64-Test/34/38
MemorySanitizer-Unit :: ./Msan-x86_64-Test/MemorySanitizer/SelectPartial
MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/34/38
MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer/SelectPartial
MemorySanitizer-Unit :: ./Msan-x86_64-with-call-Test/MemorySanitizer/SelectPartial
Profile-x86_64 :: Linux/comdat_rename.test
Profile-x86_64 :: Linux/instrprof-show-debug-info-correlation.c
Profile-x86_64 :: instrprof-dump.c
Profile-x86_64 :: instrprof-write-file-only.c
Profile-x86_64 :: instrprof-write-file.c

Test "DebugInfo/assignment-tracking/X86/remove-undef-fragment.ll" is failing on Fuchsia's Linux ARM64 Clang builder as well. Error message:

Looks like it is Fuchsia's own issue as it overrides libcxx headers in kernel (https://fuchsia.googlesource.com/fuchsia/+/658bbc3cef7f340c058dde67c3d5dd2be4084bdd/zircon/kernel/lib/ktl/include/cwchar). You don't need to take any action. Sorry for the trouble.

We are seeing build breakages in Fuchsia's builders after this change was landed and this change is in the blamelist and looks directly related:

Fixing Windows test failures.
overlay-relative flag will always using native path separator, therefore, it needs a separate base FS and OverlayYAML file setup on Windows. This diff adds this.

Address review comments

I have to revert back to use process cwd instead of base fs cwd. There are a few tests relied the behavior of using process cwd that I need to take a closer look.

Unit test failures under Windows should be fixed now.

Add additional unit test.

Patch was already landed. Not sure why it is not auto closed. Close it now.

Please take a look.

It is not just for Fuchsia, the previous change breaks all LSan build because the function declaration does not match the definition.

In D134221#3853979, @ldionne wrote:

@pcc @phosek

Can you please provide your respective minimal CMake invocations that reproduce that issue? I'll take a look.

We are seeing build failures after this change landed:

I reverted this change in a3539090884c9159893c0b2b4c1dc34f23510707. Both Fuchsia bots and LLVM TSan bots failures indicates there is a regression caused by this change and need further investigation.

In D134371#3819605, @nemanjai wrote:

This causes failures with -Werror such as: https://lab.llvm.org/buildbot/#/builders/57/builds/22322
Please fix or revert.