Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for direct CASAPI access from libToolchainCASPlugin.dylib #1415

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cachemeifyoucan
Copy link
Contributor

Add initial CAS support through libToolchainCASPlugin.dylib

Add initial CAS support through libToolchainCASPlugin.dylib
@cachemeifyoucan cachemeifyoucan force-pushed the eng/PR-swift-driver-cas-plugin-native-support branch from 6309f28 to 3be6d03 Compare August 15, 2023 17:52
@cachemeifyoucan
Copy link
Contributor Author

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

@akyrtzi
Copy link
Contributor

akyrtzi commented Aug 16, 2023

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
Copy link
Contributor Author

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
Copy link
Contributor

akyrtzi commented Aug 16, 2023

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants