No test?

Thanks!

So maybe Driver::IsCLMode() should take precedence over -fdiagnostics-absolute-paths when using /showIncludes?

Those aren't diagnostics, so that's not surprising.

What would suggest in that case? Add a new -fpreprocessor-absolute-paths option? Or change the name of -fdiagnostics-absolute-paths for another name that applies to both diagnostics and the preprocessor output?

half-address zturner comment

give NativeInjectedSource a SrcHeaderBlockEntry instead of a const_iterator

remove a dead function

Thanks!

Sorry, I missed this thread (and the other one) yesterday. Thanks for sorting out my mess; I'll think about what I want to do for the reland.

In D64640#1583265, @rnk wrote:

The traits object is only used by a few methods. Deserializing a hash
table and walking it is possible without the traits object, so it
shouldn't be required to build a dummy object for that use case.

The traits are needed to do any actual hashing.

Probably time to call ETIMEOUT on zturner. rnk, can you look at this one too given you already have seen all the prerequisite CLs? I'm pretty happy with this by now.

rebase, done

lgtm, thanks. Do you need someone to land this?

better

wip

-injected-source-content works

Thanks!

This fixes the issues mentioned at the bottom of https://reviews.llvm.org/D63109#1558181 , right?

r365721

comments

update tests

In D64506#1579251, @rnk wrote:

Does clang-cl -O0 without a / still work, though? It's used:

$ git grep O0 ../compiler-rt/test/asan/TestCases/Windows/
../compiler-rt/test/asan/TestCases/Windows/aligned_mallocs.cc:// RUN: %clang_cl_asan -O0 %s -Fe%t
../compiler-rt/test/asan/TestCases/Windows/allocators_sanity.cc:// RUN: %clang_cl_asan -O0 %s -Fe%t
../compiler-rt/test/asan/TestCases/Windows/beginthreadex.cc:// RUN: %clang_cl_asan -O0 %s -Fe%t
../compiler-rt/test/asan/TestCases/Windows/bitfield.cc:// RUN: %clang_cl_asan -O0 %s -Fe%t
../compiler-rt/test/asan/TestCases/Windows/bitfield_uaf.cc:// RUN: %clang_cl_asan -O0 %s -Fe%t
../compiler-rt/test/asan/TestCases/Windows/calloc_left_oob.cc:// RUN: %clang_cl_asan -O0 %s -Fe%t
../compiler-rt/test/asan/TestCases/Windows/calloc_right_oob.cc:// RUN: %clang_cl_asan -O0 %s -Fe%t
...

(previously: D58061)

lgtm

I did check that we now warn, like you had requested:

FYIe, you can also prevent this symbol to be linked in by putting a cxa_demangle function in an obj file that gets linked first, like so: https://cs.chromium.org/chromium/src/third_party/android_crazy_linker/src/src/crazy_linker_wrappers.cpp?type=cs&q=cxa_demangle+file:android&sq=package:chromium&g=0&l=54 – but I agree that since cxa_demangle is so large, it'd be nice if the upstream version was behind some kind of define. Then we could set that and remove that hack in chromium too. I don't have an opinion on if that should be a new define or if _LIBCXXABI_NO_EXCEPTIONS should be reused. Actually, I think we build libcxxabi with exceptions enabled because some of our test code can in theory throw exceptions, but we have an external dumper so we don't need the stack from terminate() – so it'd be somewhat more convenient for us if we could turn off the stack from terminate() (and the pulling in of __cxa_demangle) while still being able to build without setting _LIBCXXABI_NO_EXCEPTIONS.

You need to add a llvm/test/tools/llvm-objdump/lit.local.cfg that contains config.suffixes = ['.yaml'], else the .yaml files added in this change won't be run by lit.

5381 361257 out/clang/browser_tests.exe.rsp

In D64349#1574742, @rnk wrote:

lgtm

Thanks!

comments

I finished measuring the impact of this. It saves some disk, but not all that much, and it slows down links some (but not that much). If the numbers are similar on linux, maybe we shouldn't do thin archives in the llvm gn build? (Maybe the faster filesystem on linux makes hunting down all the .o files on linux less expensive, though.)