Move compile-pass tests to check-pass or build-pass

[cramertj]

compile-pass was the old way to assert that UI tests were able to successfully build. However, it would do a full build of the code, including codegen and linking. Many of our tests don't need this, however, and should instead use the new check-pass, introduced in #61778. For tests that exercise codegen and linking, build-pass can be used instead.

As a first step, it would be good to remove compile-pass to prevent users adding new tests that unconsciously take a dependency on codegen/linking, and push them to use check/build-pass to make the distinction explicit.

To do this, we'd like to start with a mass migration of compile-pass tests to build-pass (rather than check-pass because we don't want to accidentally stop testing codegen/linking functionality). However, we don't want to lose the distinction between tests which are intentionally build-pass and those that have been automatically migrated, so automatically-migrated tests should include a note like // build-pass (FIXME(this-issue-#): could be check-pass?) or similar.

Once that's done, we can remove compile-pass and work on moving over the FIXME-tagged tests to either check-pass or remove the FIXME.

[Centril]

• Mass migrate // compile-pass annotations to // build-pass (FIXME(62277): could be check-pass?).

• Remove // compile-pass from compiletest.

• Triage // build-pass annotations re. whether they should be // check-pass. (Update some build-pass ui tests to use check-pass where applicable #66087)

[Centril]

cc @petrochenkov

[monoflo]

Hi! I'm willing to take this on, but I'd like to confirm what needs to be done.

With a quick ripgrep, I've seen a ton of references with the following line:

// build-pass (FIXME(62277): could be check-pass?)

Is the goal here to go through each and every one and see what ought to be check-pass as opposed to build-pass in order to speed up testing / CI?

Per #61778 (comment):

// check-pass will compile the test skipping codegen (which is expensive and isn't supposed to fail in most cases).
// build-pass will compile and link the test without running it.
// run-pass will compile, link and run the test.

This seems like a fairly manual job that will require getting pretty familiar with the test codebase.

Where might be the best place to start chipping away at this?

[Centril]

@monoflo Basically yeah. The idea is to check whether a particular // build-pass test is just about type checking or whether codegen is relevant. I would just grep for the tests and do a few at a time.

[jyn514]

For contributors: when opening PRs, could you explain why these only need to be check-pass and not build-pass? It's easy enough to do a simple find/replace, the hard part is telling whether it needs to be build-pass or not.

• If the test is a regression test from an issue, you could either
  • test with an old version of nightly to confirm that the error it fixes was present with only cargo check (or cargo rustc -- --profile check if it's an old enough version)
  • look at the backtrace for the issue to make sure it happens before codegen
• If the test is not a regression test, but was added along with a feature, ask the original author why it was added and whether it could be check and still test everything it should.
  • If it's a trivial test that shouldn't touch codegen or linking at all, it's fine to say that without asking the author.