New command: expose --cache-cleanup=overlay base cache cleaning

[d10c]

Add new command "CodeQL: Trim Overlay Base Cache" that returns a database to the state prior to overlay evaluation, leaving only base predicates and types that may later be referenced during overlay evaluation.

• Requires a recent enough query server. So the command is hidden behind a version check.
• Tested locally and with unit tests.

[Copilot]

Pull Request Overview

This PR adds a new command "CodeQL: Trim Overlay Base Cache" to expose the --cache-cleanup=overlay functionality for cleaning base cache data. The command allows users to return a database to the state prior to overlay evaluation, keeping only base predicates and types needed for future overlay evaluation.

Key Changes:

• Implements new trimOverlayBaseCache command with corresponding message type and query server method
• Adds UI integration through command registration and handler implementation
• Updates package.json to expose the command in VS Code's command palette

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
extensions/ql-vscode/src/query-server/query-runner.ts	Adds trimOverlayBaseCacheInDatabase method to handle the new cache trimming operation
extensions/ql-vscode/src/query-server/messages.ts	Defines the trimOverlayBaseCache request type for communication with the query server
extensions/ql-vscode/src/databases/local-databases-ui.ts	Registers command and implements handler for the new trim overlay base cache functionality
extensions/ql-vscode/src/common/commands.ts	Adds type definition for the new command
extensions/ql-vscode/package.json	Exposes the new command in VS Code's command palette
extensions/ql-vscode/CHANGELOG.md	Documents the new feature addition

[koesie10]

• Requires a recent enough query server. Should I hide this command behind a version check, or just let it fail on an older CLI?

I think it would make sense to add this command behind a version check, although it would be even better to hide it behind a CLI feature (one that is returned in codeql version --format json). I see that the CLI PR hasn't been merged yet, so I think it would be best to add the feature in there. Then I think the best way to check this feature would be using something like:

cliServer.addVersionChangedListener((version) => {
  void app.commands.execute(
    "setContext",
    "codeQL.cliFeatures.yourFeatureName",
    version?.features?.yourFeatureName ?? false,
  );
});

You can then access this context in the when expression in package.json.

• I've tested this locally using a compatible build that hasn't been released yet. I suppose it means I can't add automated tests until that build is released. Should I add tests?

If you can add tests, I think that would make sense. Once your PR is included in the nightly build, you should already be able to test it there, and based on when the PR is merged you can probably also determine which actual version it will be part of to add an actual version check.

[d10c]

I've added a VSCode context variable for all the CLI features, but if that's too complicated, I can change it back to just the new CLI feature that we use.

[d10c]

I'm fine with merging the query server changes first, so that we can include an integration test in this PR.

[koesie10]

The code looks good to me. I think adding tests might be nice, but since the command is just sending a request to the query server, I don't think it's critical.

[cklin]

Looks fine from the CodeQL CLI interaction perspective 👍