Rust: Add manual regression test for dbscheme upgrade

[redsun82]

Adds a test directory with queries that verify properties are preserved when upgrading databases from rust-analyzer 0.0.301 to 0.0.328.

What this does

• old/OldShapes.ql: Queries the old schema fields (Meta, BlockExpr.isTry(), StructField.getDefault(), etc.)
• new/UpgradeShapes.ql: Queries the new schema after upgrade (PathMeta, KeyValueMeta, TryBlockModifier, etc.)
• run-test.sh: Script that automates the full test flow (checkout old commit, build old extractor, create old-schema DB, upgrade, verify)

Status

This is a one-off manual test for this specific upgrade. It is not yet checked by CI.

However, this could serve as the foundation for a general upgrade testing strategy: the pattern of "query old schema, upgrade, query new schema, compare" could be generalized and automated for future dbscheme changes.

[Copilot]

Pull request overview

Adds a manual, one-off regression test harness for validating that a Rust database schema upgrade (rust-analyzer 0.0.301 → 0.0.328) preserves key properties across the upgrade, by extracting an “old schema” DB, upgrading it, then querying the upgraded dataset.

Changes:

• Adds a run-test.sh script to automate checkout/build of an old extractor, DB creation, dataset upgrade, and verification runs.
• Adds old/new QL query pairs plus expected outputs to validate pre/post-upgrade shape preservation.
• Adds a minimal Rust source fixture + qlpack metadata and ignores generated test artifacts.

Show a summary per file

File	Description
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/run-test.sh	Automates end-to-end manual upgrade regression flow (old DB create → upgrade → verify).
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/README.md	Documents purpose, layout, and how to run the manual test.
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/old/OldShapes.ql	Old-schema query selecting fields that should be preserved through upgrade.
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/old/OldShapes.expected	Expected results for the old-schema query.
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/new/UpgradeShapes.ql	New-schema query verifying upgraded representations preserve key properties.
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/new/UpgradeShapes.expected	Expected results for the new-schema preservation query.
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/new/upgrade_shapes.rs	Rust fixture source designed to exercise upgraded schema elements.
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/new/qlpack.yml	Test pack metadata for running the new-schema verification query.
rust/ql/lib/upgrades/66a489863649185f4a9770f894505803059a1312/test/.gitignore	Ignores generated test project/db artifacts and outputs.

Copilot's findings

• Files reviewed: 9/9 changed files
• Comments generated: 2

[geoffw0]

I'm not entirely clear what this all does. I think what we're trying to do is:

• build a database of a bit of code in the new extractor, run a query, downgrade it, run query again, presumably check output is the same.
• build a database of a bit of code in the old extractor, run a query, upgrade it, run query again, presumably check output is the same.

Questions:

• do we actually test that the output is identical somewhere?
• what's the difference between lib/upgrades and upgrade-tests?
• why do we need six .ql files and four .rs files. I'd have thought we'd only need one .rs file (the code we're interested in testing with) and one or two .ql files (depending if we accept that the QL might have to change to suit the new database version; ideally it shouldn't, the libraries should absorb dbscheme differences).
• how did you select the elements you wanted to test in the queries?

[redsun82]

I'm not entirely clear what this all does. I think what we're trying to do is:

• build a database of a bit of code in the new extractor, run a query, downgrade it, run query again, presumably check output is the same.
• build a database of a bit of code in the old extractor, run a query, upgrade it, run query again, presumably check output is the same.

Yes, that is more or less the gist, but see caveats below.

Questions:

• do we actually test that the output is identical somewhere?

Not really: because the shape in the library change, it's hard in this case to request exactly the same output/results of the tests. Instead, this should rely on a human reviewer (i.e. you 😄) to inspect the expected files for before and after the upgrades/downgrades and confirm we're not losing information. The other thing that is definitely tested is database consistency before and after.

• what's the difference between lib/upgrades and upgrade-tests?

I initially had put the tests in lib/upgrades, but that poses a problem for the lib packaging (the upgrade ql tests get included), and therefore went to put them in a separate directory

• why do we need six .ql files and four .rs files. I'd have thought we'd only need one .rs file (the code we're interested in testing with) and one or two .ql files (depending if we accept that the QL might have to change to suit the new database version; ideally it shouldn't, the libraries should absorb dbscheme differences).

Uh, that is definitely an error: sorry, I forgot to git-rm the new/old directories in lib/upgrades (see above), they definitely shouldn't be there. Considering that, we get down to two rs files. It's ideally the same file, but because I chose to put the test in separate upgrade/downgrade test directories, they are separate. If we ever build this up to a proper framework, we would indeed ideally use the same source file.

• how did you select the elements you wanted to test in the queries?

I asked copilot to come up with code shapes exercising the AST changes