compiletest: Add testing for lint machinery at runtime

[clubby789]

While implementing #157707, I noticed that we don't have 'runtime' tests for the diagnostic machinery (i.e. we test the derive macros themselves, but not their output when emitted). This introduces a new way to test this machinery.

• Add //@ aux-lint: file.rs, which builds a lint library in auxiliary/file.rs
• Lint libraries link with rustc_private, and export a extern "C" fn register_lints(...)
• A new compiletest-lint-driver wraps rustc and installs the provided lints when building the test

Included is a simple demo lint for example

AI Disclosure: I used an LLM to plan out the broad structure of the machinery and identify issues; all code in this PR is written by hand

[rustbot]

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

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in src/tools/compiletest

cc @jieyouxu

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @jieyouxu, @oli-obk, @wesleywiser, bootstrap
• @jieyouxu, @oli-obk, @wesleywiser, bootstrap expanded to 8 candidates
• Random selection from Mark-Simulacrum, jieyouxu, oli-obk, wesleywiser

[rustbot]

rustc-dev-guide is developed in its own repository. If possible, consider making this change to rust-lang/rustc-dev-guide instead.

cc @BoxyUwU, @tshepang

[clubby789]

This does add some tool+std builds unconditionally to any ui-fulldeps invoke; this should hopefully be relatively low impact in practice

View changes since the review

[clubby789]

Just because I'm a little unsure on the correctness of some of the logic:
@bors try jobs=x86_64-gnu-stable,dist-x86_64-msvc

[rust-bors]

☀️ Try build successful (CI)
Build commit: e1663b0 (e1663b0b8baea0aa95b6292be893d0340b542cf1, parent: 485ec3fbcc12fa14ef6596dabb125ad710499c9e)

[Mark-Simulacrum]

we test the derive macros themselves, but not their output when emitted

I'm a bit confused (probably just missing something...)... but aren't those macros tested by every diagnostics-related UI test in the existing suite? It's an indirect test but it should still catch bugs in practice, right?

If we wanted to test the raw output, I'd expect that to be done with something more like proc-macro2 + insta to snapshot test what is produced by the macro?

I think in general it would make sense to make a compiler MCP for this since it'll at minimum make it a bit more painful to edit the lint infrastructure.

[clubby789]

'Output' as in the runtime diagnostics emission. The machinery in general is tested, but when introducing new features to the system (i.e. lint MSRV) it would be nice to test the edge cases of behaviour.

An MCP probably does make sense here though.

[clubby789]

MCP: rust-lang/compiler-team#1004