compiletest: make some internals pub for use as a library

[akintewe]

Make Config, TestPaths, CollectedTest, CollectedTestDesc, ShouldFail, FileDirectives, parse_config and collect_and_make_tests public so that external tools can depend on compiletest as a library and use its test collection infrastructure directly, without re-implementing parts of bootstrap and compiletest.

r? jackh726

[rustbot]

compiletest directives have been modified. Please add or update docs for the
new or modified directive in src/doc/rustc-dev-guide/.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Zalathar]

In the past, stuff like this has been detrimental to compiletest maintenance, so I'm very reluctant to expose anything beyond the absolute bare minimum needed by other in-tree tools.

If you need these details for out-of-tree tools, I'd prefer that the changes be kept in a downstream fork instead, so that they don't burden compiletest itself.

[akintewe]

In the past, stuff like this has been detrimental to compiletest maintenance, so I'm very reluctant to expose anything beyond the absolute bare minimum needed by other in-tree tools.

If you need these details for out-of-tree tools, I'd prefer that the changes be kept in a downstream fork instead, so that they don't burden compiletest itself.

Thanks for the feedback @Zalathar. The intended use is an in tree tool (src/tools/coverage-tool) that depends on compiletest as a library to collect tests without re implementing bootstrap's test collection logic so the changes would live in tree alongside compiletest, not in a downstream fork.

That said, I completely understand the concern about maintenance burden. @jackh726 given this feedback, would it make more sense to keep the coverage tool self contained and duplicate the minimal bits it needs from compiletest instead?

[Zalathar]

The name coverage-tool also seems liable to be confusing.

I'm not very familiar with your current work, but if the tool is intended to help measure coverage of the compiler itself, it might be wise to communicate that more clearly in the tool's name (e.g. compiler-coverage-tool), to help distinguish it from existing tools and tests related to the implementation of coverage instrumentation.

[akintewe]

The name coverage-tool also seems liable to be confusing.

I'm not very familiar with your current work, but if the tool is intended to help measure coverage of the compiler itself, it might be wise to communicate that more clearly in the tool's name (e.g. compiler-coverage-tool), to help distinguish it from existing tools and tests related to the implementation of coverage instrumentation.

Thank you for the suggestion, compiler-coverage-tool is much clearer. I'll rename it.
And i understand on the maintenance concern. I'll wait to hear from @jackh726 on whether it makes more sense to keep compiletest changes minimal and have the tool duplicate what it needs instead.