[WIP] [test] Switch %clang-importer-sdk over to using parseable interfaces #20957
Conversation
|
@swift-ci Please test |
|
The high addition count is just from copying the existing mock overlay sources over and tweaking them to be valid/good swiftinterfaces. |
|
Cool! |
|
Build failed |
|
Build failed |
...or where they're already using %clang-importer-sdk, which implies it.
We can't remove the non-parseable-interface mock overlays yet because of all the existing code using %clang-importer-sdk-nosource and manually compiling the overlays, but this is a start!
jrose-apple
force-pushed
the
interface-your-fears
branch
from
7c327d2 to
f84008a
Compare
|
I think this is still a lot slower than running the tests the normal way, and I need to find out why, but to check that it's not just my laptop… @swift-ci Please test |
|
Build failed |
|
Confirmed slow. :-( |
|
@jrose-apple Should we close this then? |
|
I think it's still desirable to get to a place where this works, because the current clang-importer-sdk mechanisms are a hack. But it's gonna have to be owned by someone other than me. I'll close it but leave the branch around. |
4 participants
The mock SDK has mock overlays to go with its mock headers, and until now such overlays have always been manually compiled to swiftmodules or included via the old-and-broken -enable-source-import. Instead, we can use the new-and-exciting swiftinterface format to have them automatically compiled and cached each test run.
Still to fix:
Move all the "-enable-source-import hackaround" manual compilers of overlays over to this.
Dependency tracking is including the cached module files, which seems like a bad idea. (See test/Frontend/dependencies.swift.)
We're definitely compiling the same swiftinterface with more than one configuration in the same compilation, and we need to not do that. (I suspect this is the difference between a top-level import and a recursive import.)