[ParseableInterfaces] Add -prebuilt-module-cache-path to the frontend #21398
Conversation
When trying to load a swiftinterface, search this directory before doing all the work of building a swiftmodule.
Makes this code easier to read. No functionality change.
| // .swiftinterface. | ||
| // If we have a prebuilt cache path, check that too if the interface comes | ||
| // from the SDK. | ||
| if (!PrebuiltCacheDir.empty()) { |
There was a problem hiding this comment.
This logic checks the prebuilt cache dir first. I don't like this because it slows down the case where the module is not in the prebuilt cache; the alternative would be to fall back to the prebuilt cache and then copy the prebuilt artifact into the proper cache. The downside(s) of that: What if the copy fails? What if it's nonatomic? What if someone's deliberately set things up so that using prebuilt artifacts is okay, but nothing else should get built?
(I was a little unhappy to see that llvm::sys::fs::copy_file is just reading and writing buffered chunks instead of using a system native API. That might be worth fixing on its own.)
There was a problem hiding this comment.
I don't think the extra stats here are worth worrying about. Entire modules are comparatively large units of granularity; the system is doing a ton more stat-work examining individual file dependencies.
There was a problem hiding this comment.
It's less the stats I'm worried about than the dependency checking, i.e. "the prebuilt version is present but I've modified my SDK for whatever reason". Or even, to a lesser extent, "the prebuilt version is present but I'm using a custom-built toolchain".
|
@swift-ci Please test |
|
Build failed |
|
@swift-ci Please test Linux |
|
I discovered a silly bug: this works at the top level, but I forgot to pass it down to the sub-invocation to handle indirect imports. Fix coming soon. |
|
Merged as part of #21513. |
When trying to load a swiftinterface, search this directory before doing all the work of building a swiftmodule.