Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
swift and clang write index data based on the status of what resides in `index-store-path`. When using a transient per-swift-library index, it writes O( M imports * N libs) indexer data and slows down compilation significantly: to the tune of 300% slow down and 6GB+ index data in my testing. Bazel likes to use per `swift_library` data in order to remote cache them, which needs extra consideration to work with the design of swift and clang and preserve the performance This PR does 2 things to make index while building use the original model of the index-store so we don't have to patch clang and swift for this yet. When the flag `-Xwrapped-swift-enable-global-index-store` is set: 1. it writes to a global index cache, `bazel-out/global_index_store` 2. it copies indexstore data (records and units) to where Bazel expected them for caching: e.g. the original location with `swift.index_while_building` Note that while this uses a `index-import` binary, it is very different than how index-import currently works. In the variant this expects, it is program that can _copy_ index data for specific compiler outputs. This has the effect fo remote caching the subset that was used in compilation for this library. I added a detailed description of this feature in the RFC to add it there MobileNativeFoundation/index-import#53. In practice, transitive imports will be indexed by deps and if they aren't cached then the fallback is Xcode wil index transitive files if we set those as deps on the unit files
- Loading branch information