Add support for direct CASAPI access from libToolchainCASPlugin.dylib

[cachemeifyoucan]

Add initial CAS support through libToolchainCASPlugin.dylib

[cachemeifyoucan]

Currently only implements store action in plugin CAS as it is the only one needed for now.
Depends on swiftlang/swift#67942

[akyrtzi]

Could you clarify what the overall goal and design of CAS access is? For example it's not clear to me how direct access to the C API of the plugin relates to the swiftscan_cas_create_from_plugin/swiftscan_cas_store APIs. When is it intended to call swiftscan_cas_store and when is the plugin C API store called instead?

My first thought is that we could do what we did for libclang where we have higher-level libclang APIs that represent the CAS-related actions and we don't expose low-level access to direct CAS objects & APIs. Whether the C plugin ends-up getting used or direct on-disk CAS is just a configuration change, it doesn't even change the code-paths in libclang (it uses the C++ ObjectStore/ActionCache APIs).
Should we do something similar here (have higher level swiftscan_ APIs for driver-related CAS/caching actions) and avoid low-level CAS APIs?

[cachemeifyoucan]

Could you clarify what the overall goal and design of CAS access is? For example it's not clear to me how direct access to the C API of the plugin relates to the swiftscan_cas_create_from_plugin/swiftscan_cas_store APIs. When is it intended to call swiftscan_cas_store and when is the plugin C API store called instead?

It is not related. Maybe I should break that apart into two commits/PRs. Scanner will keep its own CAS instance (can be created from plugin after this commit), while giving the option for swift driver to have direct CAS access without going through scanner and owns a difference CAS instance.

My first thought is that we could do what we did for libclang where we have higher-level libclang APIs that represent the CAS-related actions and we don't expose low-level access to direct CAS objects & APIs. Whether the C plugin ends-up getting used or direct on-disk CAS is just a configuration change, it doesn't even change the code-paths in libclang (it uses the C++ ObjectStore/ActionCache APIs). Should we do something similar here (have higher level swiftscan_ APIs for driver-related CAS/caching actions) and avoid low-level CAS APIs?

For short term, we can definitely go through swift scan API for all the CAS operations. The direct CAS access allows converting more scanner logic into swift code.

[akyrtzi]

Scanner will keep its own CAS instance (can be created from plugin after this commit), while giving the option for swift driver to have direct CAS access without going through scanner and owns a difference CAS instance.

Is the intention that these are exclusionary? Meaning, the CAS scanner APIs will be used until the driver moves fully to direct CAS access and at which point we'll deprecate the CAS scanner APIs?
Or are they both going to be used at the same time for different purposes?

[cachemeifyoucan]

Is the intention that these are exclusionary? Meaning, the CAS scanner APIs will be used until the driver moves fully to direct CAS access and at which point we'll deprecate the CAS scanner APIs? Or are they both going to be used at the same time for different purposes?

Depending how much of the depscanner can be written in swift, both will co-exist for a long time. It doesn't really hurt to have scanner and driver each have its own CAS instance which points to the same CAS, just like each swift-frontend invocation will have its own CAS instance pointing to the shared underlying CAS.

If the driver has its own CAS, I might just completely implement the CAS replay logic in swift driver. Otherwise, we can always get some new scanner API that does the replay.

[cachemeifyoucan]

Split out the pluginCAS support in SwiftScan to https://github.com/apple/swift-driver/pull/1422/files

Will rebase this once the other PR is resolved.