jansvoboda11 added a comment. > And it is build system's responsibility to provide `-ivfsoverlay` options > that don't cause observable differences.
I wasn't aware of that. Do we document this anywhere? It surprises me that we'd impose such restriction on the build system. This seems fairly easy to accidentally violate and end up in the same situation - Clang instances with different VFS overlays, identical context hashes and different canonical module map paths for the same module. What are the performance implications of making VFS overlays part of the context hash? Alternatively, we could keep VFS overlays out of the context hash but create `<hash2>` from the on-disk real path of the defining module map and make the whole PCM VFS-agnostic. Then it'd be correct to import that PCM regardless of the specific VFS overlay setup, as long as all VFS queries of the importer resolve the same way they resolved within the instance that built the PCM. Maybe we can force the importer to recompile the PCM if that's not the case, similar to what we do for diagnostic options. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156749/new/ https://reviews.llvm.org/D156749 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
