Rust qlref inline-expectation audit: no safe conversions in current non-inline set

[Copilot]

This updates the Rust conversion effort by applying the qlref-to-inline-expectation criteria to all remaining non-inline .qlref tests in scope. The current set contains no standard @kind problem/@kind path-problem candidates that can be converted without making tests misleading or noisy.

• Scope and outcome

  • Audited all Rust .qlref files not yet using utils/test/InlineExpectationsTestQuery.ql.
  • Result: 0 conversions; all remaining cases are explicitly classed as skip candidates.

• Skip classification applied

  • Structural/library/extractor tests: AST/CFG/type/path/definitions-style outputs (non-alert semantics).
  • Diagnostics/metrics/integration summary tests: @kind diagnostic / @kind metric query families.
  • Special inline-flow framework tests: InlineFlow.qlref under taint source suites, where expectations are framework-driven (hasTaintFlow) rather than clean Alert/Source/Sink mapping.

• Formatting and safety constraints preserved

  • No .expected files edited.
  • No source annotations injected into shared/generated fixtures.
  • Existing non-inline tests remain unchanged until/if a query-specific conversion strategy is defined.

Example of a currently skipped pattern (framework-specific inline flow expectations, not standard Alert/Source/Sink conversion target):

let _bytes = std::io::stdin().read(&mut buffer)?; // $ Alert[rust/summary/taint-sources]
sink(&buffer); // $ hasTaintFlow

Original prompt

Follow these instructions for Rust.

qlref conversion instructions

Here’s the repeatable recipe for converting a CodeQL language’s .qlref tests to inline expectation tests.

Overall Workflow

1. cd into the language folder.

2. Run grep -rL "InlineExpectationsTestQuery" --include="*.qlref".

3. Ignore generated .actual files, .testproj copies, and other generated artifacts.

4. For each .qlref, resolve the referenced query and read its metadata.

5. Classify each test before editing:

  - convert now for standard @kind problem and @kind path-problem

  - skip for anything else, with a short concrete reason

6. Inspect the existing .expected file before converting:

  - If it is empty and the query is a standard problem or path-problem query, usually convert by adding the postprocessor only. No source comments are needed.

  - If it is non-empty, add inline expectation comments to the source files at the expected result locations, then add the postprocessor to the .qlref.

7. Keep the existing .expected file. Do not edit generated expected files by hand, even when converting.

8. Edit only source files and .qlref files.

9. Maintain a skip list for tests not converted, with exact paths and short reasons.

10. Do not make a PR.

.qlref Formatting

For a single postprocessor, use the compact form:

query: path/to/Query.ql

postprocess: utils/test/InlineExpectationsTestQuery.ql

If the .qlref already has other postprocessors, use list form:

query: path/to/Query.ql

postprocess:

  - utils/test/PrettyPrintModels.ql

  - utils/test/InlineExpectationsTestQuery.ql

If the original .qlref was a plain single-line query reference, convert it to query: form only when adding postprocess:.

Always preserve existing postprocessors.

Expectation Comments

Use the language’s supported inline comment syntax from its inline expectation implementation. Typical tags are:

$ Alert

$ Source

$ Sink

For example, in Java or Kotlin:

sink(userInput); // $ Alert

For problem queries, add Alert at each expected result location.

For path-problem queries, add:

• Alert at the alert location.

• Source at the source location, unless the source is on the same line as the alert.

• Sink at the sink location when it is a distinct relevant location.

Multi-line result locations should be annotated on the end line.

If more than one result is expected on the same line for the same query, just use a single tag in the comment, for example:

foo(bar); // $ Alert

Only add comments to real source files that belong to the test. Do not annotate generated copies, shared vendored fixtures, or shared stubs unless that is clearly the right ownership boundary for the test.

Empty .expected Files

If a problem or path-problem test already has an empty .expected file, the default conversion is:

1. Leave .expected untouched.

2. Add postprocess: utils/test/InlineExpectationsTestQuery.ql to the .qlref.

3. Add no source comments unless the test actually has expected results that are currently represented elsewhere.

This is common in zero-result tests.

Query Ids

Do not add [query-id] by default.

Only qualify tags when needed, usually when more than one inline expectation test in the same effective test folder or database can see the same source comments. Then use the query’s metadata id:

response.write(x); // $ Alert[java/xss]

Apply this to Alert, Source, and Sink only for the comments that need disambiguation.

If you add query ids in a shared folder, validate the owner queries for those comments as well, not just the query you were editing.

Good Skip Reasons

Skip, or revert to non-inline, when conversion would make the test misleading, brittle, or noisy. Common reasons:

• The query is not @kind problem or @kind path-problem.

• The query is a telemetry, metrics, table, definitions, diagnostic, extractor-information, stub-generation, or tool-specific query.

• The test is an AST dump or similar structural output test, such as PrintAst.

• The selected result text is inside a string literal, raw string, heredoc, text block, XML literal, or multiline literal and adding a comment changes the selected text.

• The expected location is inside documentation syntax where adding a comment changes what the query reports, such as Javadoc tags.

• The .expected output is nonstandard enough that mechanical conversion is risky.

• Results are in shared stubs, generated copies, vendored files, or synthetic/test-project paths where inline comments would pollute shared fixtures.

• The alert, source, or sink locations are too dense or ambiguous to make the source understandable.

• The language’s inline expectation implementation does not support the source file or comment style needed.

• The query uses a special result kind or framework behavior, such as alert-...

Created from VS Code.