Thanks again everyone!

Update help

Update test and docs

Add flag to test

Thanks for driving that! Updated my patch to use --quiet. I did hesitate a bit on specifically saying 'no symbols' in the help string, but I guess we can update that in the future if anything else makes sense to gate with this flag as well.

Update to --quiet spelling

No worries! Makes sense, I think this is a good change

I personally prefer this, and this is what I landed in swiftc a while back, but I changed to -fprofile-prefix-map based on feedback from you 😛 https://reviews.llvm.org/D83154?id=275480#2146086

I think it is case by case. For this one, 2> /dev/null is a simple and easy workaround. I find it difficult to argue against this choice. There was an equally good suggestion --quiet we cannot refute.

thanks for the review

Yea seems like a reasonable request, looking through the uses nothing immediately pops out as being not supporting multiple PCHs but I guess before I went down that path I'd want someone who knew the code better to agree on that

Update style in test

Fair question! I think this case is a bit different since it's quite subtle. The strange thing here is that the header you're intending to provide a pch for can still be read successfully, but not getting the benefits of the pch that you were expecting without knowing about it.

Add group to warning

Looks like this broken a build http://green.lab.llvm.org/green/job/ZorgTests/49794/console

No problem, thanks!!

Something went wrong with this being attached to the commit (I believe because I committed from a different machine than I originally wrote this on), landed here https://github.com/llvm/llvm-project/commit/c3324450b204392169d4ec7172cb32f74c03e376 thanks for the review!

Rebase

Yes sorry, big company reviews month. I will try to land Friday

I'm a bit worried that without a repro case (outside of the missing newline) Apple won't get around to fixing this, and in the meantime I'm wondering if outside of the chromium build system folks will experience this. I wonder if there's an acceptable alternative here such as adding a (ideally temporary) flag to force the old behavior?

It looks like at least in the -Wl case clang passes the file through directly, so I'm not surprises that it repros there:

Note in your repro case the issue is that the response file doesn't end in a trailing newline

Note the test case shown here passes on master, so we can drop this

Thanks! I actually just requested access so we'll see!

Thanks! I don't have commit access do you mind landing this for me?

Thanks! I don't have merge access do you mind helping me land this?

Thanks all! Can someone land this for me again?

Make function static

Thanks!

Remove unused enum

Thanks for the review!

Address review comments

I believe my author info was correct, but I've updated it using the command mentioned in the doc. Thanks!

Update author

Thanks! I don't have merge access can you help me land this?

Add comment about recalculation

Rename to -prepend_rpath

Should we wait for that one to land and then pick this one up? Otherwise any thoughts on the outstanding discussion?

With D87928 do you think we would want this flag as well? The only difference I can think of (besides general UX) is if you need to remap paths outside of your source root, I believe having a *-prefix-map style flag makes that a bit more clear (or potentially possible at all). Ideally there wouldn't be issues around that but in the past in the Apple toolchain the Xcode path was embedded in debug info (as an example), so to get a reproducible build we had to pass -fdebug-prefix-map=/path/to/Xcode.app=SOMETHING. Which -fdebug-compilation-dir . couldn't solve. I'm wondering if we should add both flags for this flexibility, or if we should assume this should not happen?

In D87928#2282609, @phosek wrote:

This change is trying to address the issues raised in D83154. There are still some open questions:

• Is -fsource-dir the best name for this flag?

Small fixes

Rename from fcoverage-prefix-map to fprofile-prefix-map

Yes I do, sorry I've been a bit busy, I will try to get to this later this week

Is there a build step executing llvm-nm that chokes on this? Can you say more about the use case?

I originally implemented this behavior behind -fdebug-prefix-map but there was some pushback, more context: https://lists.llvm.org/pipermail/cfe-dev/2020-June/065668.html

In D83152#2133950, @rupprecht wrote:

In D83152#2133855, @MaskRay wrote:

I cannot find any search result about no-warning-for-no-symbols. Is -no-warning-for-no-symbols really an existing option? libtool is an ar like tool.

I found it by looking for underscores instead of hyphens: -no_warning_for_no_symbols.
However, the flag is an ar/ranlib/libtool flag, not nm, AFAICT.

Fix tests on Windows

Open question: I don't know how all the toolchains fit together, but I noticed that only Clang.cpp handles -fmacro-prefix-map, but Clang.cpp, FreeBSD.cpp, and Gnu.cpp all handle -fdebug-prefix-map. I wasn't sure which pattern I should follow here, so right now this only adds the handling to Clang.cpp, please let me know if that's not appropriate in this case!

https://reviews.llvm.org/D83154