benlangmuir added a comment. In D142780#4087250 <https://reviews.llvm.org/D142780#4087250>, @rmaz wrote:
> In that case we are seeing non-deterministic header paths serialized in pcm > files. IIUC the header files are serialized based in their unique ID, so it > wouldn't be possible to handle this case, is this right? If compiling a single pcm accesses multiple hard links with the same UID, then it would not be possible to use the set of UIDs to get the "right path". At best we could make it get a deterministic path -- e.g. if we tracked the order of access. If compiling a single pcm accesses only one hard link but it's an implicit module build and the overall compiler invocation accesses another one with the same UID, you are currently in the same situation as above, though in theory you could avoid it by not sharing the FileManager across implicit module builds. In clang-scan-deps we don't share the FileManager and we get away with it because we have a separate filesystem caching layer. In a normal implicit modules build I don't know how much this would cost. If you're on a platform that supports `fcntl` with `F_GETPATH` such as Darwin, another possible source of non-determinism is that the underlying OS may return a non-deterministic `RealPath` from `openFileForRead` when there are multiple hard links. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D142780/new/ https://reviews.llvm.org/D142780 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
