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

https://reviews.llvm.org/D83015

Awesome!

No problem, thanks!

@fhahn can you help land this? I don't have access. The failure does appear to be related but it seems like just applying this patch is failing, which I don't understand

FYI I actually removed that piece this morning since I felt like since this now supports -path-equivalence=.,foo which is the "expected" behavior from lldb, that was "good enough". lmk if you want me to add it back!

Update relative paths to include the leading ./

Fix test on windows

The new test failure appears unrelated to my changes

Update tests

Thanks I moved them to the bottom and I believe I fixed them on windows!

I've submitted a related change to accept relative paths for -fuse-ld https://reviews.llvm.org/D80660

Can someone land this for me? I don't have permissions to do that AFAIK

No worries, thanks!

No problem! Yes please! :)

• Hoist LLDB.framework headers copy out of condition

• Make headers a post build command

It seems like if this was a common occurrence, it would've been fixed earlier, so I'm wondering if there's a difference in the way I'm building lldb that causes this. Using cmake: