[SwiftScan] Add SwiftScan APIs to replay the cache output

[cachemeifyoucan]

Add new C APIs to libSwiftScan for cache querying and cache replays.

[cachemeifyoucan]

I was trying to abstract out the compilation to avoid re-parsing command line, compute input/output and create instance in replay logics, but it turns out a lots of information needs to be passed, including:

• the diagnostics needed
• how to print diagnostics (color, format, etc.)
• (added) prefix map for cache replay
• inputs (to compute how to construct file specific diagnostic consumer)
• outputs (to replay)

So stick with replaying from command-line for now.

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[akyrtzi]

The libclang API has this kind of interaction with the build system:

1. key query API call: if the key exists it returns an abstract object that represents the outputs (the outputs are not downloaded from this call)
2. outputs materialize API call: downloads outputs locally
3. replay API call: receives arguments and the abstract object for outputs

Separating (1) from (2) provides flexibility on the client side for treating them as separate actions that can be recorded in the build log with their own timing info and executed potentially with different priority/scheduling. I would prefer to preserve that for swift as well instead of swiftscan_cache_query bundling both actions into the same API call.

And once an opaque object for outputs is introduced you can pass it to swiftscan_cache_replay_compilation to formalize that the outputs must already be found and potentially simplify the work that the replay function needs to do.

[cachemeifyoucan]

Separating (1) from (2) provides flexibility on the client side for treating them as separate actions that can be recorded in the build log with their own timing info and executed potentially with different priority/scheduling. I would prefer to preserve that for swift as well instead of swiftscan_cache_query bundling both actions into the same API call.

Maybe. But isn't that more round trip to remote that just adds latency? Maybe query can return faster without download, but what do you do if query succeed but materialize failed? Isn't that the same as a miss?

[akyrtzi]

But isn't that more round trip to remote that just adds latency?

Key/value queries are separated from CAS actions, both in the LLVMCAS APIs and the network protocols, there's no saving of latency in putting them behind one C API function instead of two.

Maybe query can return faster without download, but what do you do if query succeed but materialize failed? Isn't that the same as a miss?

Yes, the client should treat it as a miss (or not, it is up to the client, maybe in a more strict mode it prefers to fail if the CAS download was not found, that's the benefit of the additional flexibility and control) and it will be more transparent to the client what exact action failed.

[cachemeifyoucan]

Split queryCacheKey and loadObject into different API. Add a reserved field in replay function in case we want to add in the cache keys in the future.

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please test

[benlangmuir]

I'm a bit unclear on the intended design for the replay function. Currently it works by triggering a performFrontend that internally does the caching. IIUC that will replay all the cached compilations associated with that frontend job in the case of batch mode. But if we have multiple keys for that and you have added one key parameter to the function for future use, won't you then need to make multiple calls to the same function?

I wonder if we should have a list of keys instead? I assume that even after you stop using performFrontend, you need to setup some state from the compiler arguments to do the replay. That seems like something we want to avoid repeating multiple times for the same invocation if possible.

[cachemeifyoucan]

I'm a bit unclear on the intended design for the replay function. Currently it works by triggering a performFrontend that internally does the caching. IIUC that will replay all the cached compilations associated with that frontend job in the case of batch mode. But if we have multiple keys for that and you have added one key parameter to the function for future use, won't you then need to make multiple calls to the same function?

I wonder if we should have a list of keys instead? I assume that even after you stop using performFrontend, you need to setup some state from the compiler arguments to do the replay. That seems like something we want to avoid repeating multiple times for the same invocation if possible.

See my comment in the beginning. #68660 (comment)

The ideal situation is to replay from each key but the number of API required will grow significantly and might not be very stable. I was thinking if there are better way to communicate (like setup replay state from a JSON or a CAS object).

[cachemeifyoucan]

After offline discussion, we are going to revise the cache key structure and this patch will be updated with the new design in mind later.

[cachemeifyoucan]

Update the patch to using the new cache key schema and new C APIs.

Add a tool swift-scan-test that can be used to test libswiftscan C APIs.

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

Also rewrite the patch to split Caching related code from DependencyScanning related code in libSwiftScan implementation so the file gets smaller and easier to read.

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[akyrtzi]

Could you add a swiftscan_cached_output_get_casidstring function, it will be useful for the client for logging purposes.

I also foresee a need for something like swiftscan_cache_compilation_is_uncacheable, for the case that the compiler decided that the compilation was uncacheable, so the client can distinguish this case. I'd suggest to add the function as a stub (always returning false) so clients can call it, and implement it properly in a future PR once we find a case for marking a key as 'uncacheable'.

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[cachemeifyoucan]

@swift-ci please smoke test

[akyrtzi]

Thank you for addressing all the feedback!

[cachemeifyoucan]

@swift-ci please smoke test windows platform