User Details
- User Since
- Jun 25 2018, 2:18 PM (145 w, 5 d)
Mar 7 2021
Thanks again everyone!
Update help
Mar 5 2021
Update test and docs
Feb 27 2021
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
Feb 25 2021
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
Feb 9 2021
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
Jan 25 2021
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
Jan 20 2021
Yes sorry, big company reviews month. I will try to land Friday
Dec 1 2020
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?
Nov 30 2020
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
Nov 20 2020
Nov 18 2020
Nov 16 2020
Note the test case shown here passes on master, so we can drop this
Nov 9 2020
Nov 2 2020
Oct 30 2020
Oct 29 2020
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?
Oct 28 2020
Thanks all! Can someone land this for me again?
Oct 23 2020
Oct 21 2020
Make function static
Oct 20 2020
Thanks!
Remove unused enum
Thanks for the review!
Address review comments
Oct 19 2020
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
Oct 16 2020
Rename to -prepend_rpath
Sep 22 2020
Should we wait for that one to land and then pick this one up? Otherwise any thoughts on the outstanding discussion?
Sep 21 2020
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?
Sep 15 2020
Sep 12 2020
Sep 9 2020
Small fixes
Sep 8 2020
Rename from fcoverage-prefix-map to fprofile-prefix-map
Aug 18 2020
Yes I do, sorry I've been a bit busy, I will try to get to this later this week
Jul 16 2020
Is there a build step executing llvm-nm that chokes on this? Can you say more about the use case?
Jul 14 2020
Jul 6 2020
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
Jul 4 2020
Fix tests on Windows
Jul 3 2020
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!