This patch makes clang-scan-deps use the virtual path for module maps instead of the on disk path. This is needed so that modulemap relative lookups are done correctly in the actual module builds. The file dependencies still use the on disk path as that's what matters for build invalidation.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
There were two issues for Windows.
The first is an actual bug in the Clang VFS that should be fixed separately. You cannot pass just main.m as the input to Clang. Clang asks for its parent directory textually, which is .. It then tries to stat ., which the VFS rejects. Not sure why it's OK on non-Windows.
The other issue is not handling path separators in the FileCheck test. Fixed by adding sed 's:\\\\\?:/:g'.
I'm uploading a new patch and will commit on clean precommit tests.
clang/test/ClangScanDeps/modulemap-via-vfs.m | ||
---|---|---|
6–7 | There seems to be a problem with this test: it's writing a module cache to the current working directory instead of writing it into somewhere under %t. Presumably this just requires adding a module cache path parameter? |
clang/test/ClangScanDeps/modulemap-via-vfs.m | ||
---|---|---|
6–7 | I think the easiest fix is to change the command string in the json below, to update the passed -fmodules-cache-path. I'm working on a patch right now. |
@Bigcheese have you got a fix for the vfs issue with . and ..?
Looking closely at your comment, I'm surprised you landed this without an llvm-lit xfail for windows, given your comment above.
Update: I'm going to revert this on main. This patch was accepted conditionally on you fixing the windows crash, which you have not done, so this was landed without being accepted.
Revert is here: https://reviews.llvm.org/rGea835171389a
When you re-land this, don't forget to include the changes from D116611, please.
There is no crash on Windows with this patch. The issue is if you pass main.m instead of DIR/main.m. The commit that landed had both fixes I mentioned. Did you try this on Windows or look at the bots? In the future please be more careful.
I did try this on windows, and I'm still seeing a crash about traversal segments, I'll continue investigating that crash.
@Bigcheese I am sorry - after a lot of further investigation, it was due to an odd interaction with some downstream changes. I will re-land your changes, with correct attribution to you.
There seems to be a problem with this test: it's writing a module cache to the current working directory instead of writing it into somewhere under %t. Presumably this just requires adding a module cache path parameter?