⚠️ The head of this PR and the base branch were compared for differences in the framework coverage reports. The generated reports are available in the artifacts of this workflow run. The differences will be picked up by the nightly job after the PR gets merged. The differences can be found in the comparison artifact of this workflow run.

⚠️ The head of this PR and the base branch were compared for differences in the framework coverage reports. The generated reports are available in the artifacts of this workflow run. The differences will be picked up by the nightly job after the PR gets merged. The differences can be found in the comparison artifact of this workflow run.

⚠️ The head of this PR and the base branch were compared for differences in the framework coverage reports. A recent commit removed the previously reported differences.

Force pushed to rebase this refactor to main instead of building on top of previous PRs. This should facilitate the review.

This definitely changes the performance characteristics of these 3 queries, and it no longer makes sense for SensitiveSource.flowsToCached to be cached. This may be perfectly fine, but you should make sure to do a thorough performance evaluation.

@aschackmull performance evaluation done. Apparently there's no negative impact on performance after this PR (CleartextStorageProperties.ql took +164s but CleartextStorageCookie.ql took -223s, so it seems like a normal tradeoff depending on which query runs first, plus a ~60s improvement).

Still not sure why the integration tests are failing though.

Do you have a link to the perf eval?

Thanks for your comments @aschackmull, applied in b52a2cd.