Context

There is currently only one test for save_analysis. This test ensures that the compiler doesn't crash when dumping crate information as a text file. The lack of further tests allows bugs to be (re)introduced (e.g. #33213) and makes it difficult to make modifications to the API with confidence. It is important to increase the reliability of save_analysis, since the future RLS will be implemented on top of it.

Requirements

Ideally, we should come up with a clear testing architecture to deal with this problem. It would need to:

• Run the compiler on a given program and extract the analysis information: a possible way to do this would be to write a struct that implements the Dump trait and collects all available information about a program in Vecs (see below).

struct Analysis {
    pub struct_defs: Vec<StructData>,
    pub trait_defs: Vec<TraitData>,
    pub globs: Vec<GlobData>, 
    ...
}

• Compare the obtained analysis information to previously defined criteria. We could start by testing names, spans and correct cross-referencing.

Integrating with rustc's testing system

Currently, the only test is in src/test/run-make/save-analysis. This makes sense for checking whether ICEs are triggered, but is probably unsuitable for the fine-grained testing approach described above.

We could follow the approach of rustdoc and the pretty printer. For instance, we could add a new directory (src/test/save-analysis) and put the tests there. We should probably begin with single-file tests.

A possible way to encode the constraints of the tests is through comments, as shown below:

fn foo() {
// ^^^, function definition, name: foo
}

fn main() {
// ^^^^, function definition, name: main
    foo();
 // ^^^, function call, name: foo, references: 1.3-1.5
}

Notation:

• ^^^: the span of the item.
• 1.3-1.5: a span beginning on the third column of the first line and ending on the fifth column of the first line.