compiletest: what does --pass (pass mode) actually intend to do?

[jieyouxu]

Apparently compiletest has a --pass flag which allows setting "pass mode" but it's unclear what that is intended to do. AFAIK, many tests don't account for this at all, and //@ ignore-pass is apparently a directive which is used liberally. CI doesn't seem to have fanatastic coverage for --pass configurations either. It might also be a specific thing for a subset of test suites. And also, how does the current implementation compare to the intended behavior / use case.

See https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20CI-only.20failure.20in.20new.20test/near/477973621 for some discussions.

[Zalathar]

For archaeological reference, --pass and //@ ignore-pass appear to have been added in #61755.

There also appears to be some motivation briefly mentioned in the associated #61778.

[jieyouxu]

That PR itself is builtin upon #61778.
EDIT: ah, I found important context:

#61755 will provide a way to run the tests with any mode, e.g. bump check-pass tests to run-pass to satisfy especially suspicious people, and be able to make sure that codegen doesn't breaks in some entirely unexpected way.

Also in #61755:

On my machine, ./x.py -i test src/test/run-pass --stage 1 --pass check takes 38 seconds whereas it takes 2 min 7 seconds without --pass check.

[jieyouxu]

TL;DR: pass mode seems to be a mechanism to allow someone to forcefully modify how deep into the compilation or test running pipeline (check vs build vs run) the tests will be evaluated at. //@ ignore-pass is the opt-out, and this seems to be used as an escape hatch because PR CI I think uses --pass=check to force downgrade some ui tests to run them at a lower test running pipeline to save CI time?

[ehuss]

In practice, I think --pass=check is the only mode override used. If you are not doing codegen work, it makes the ui tests much faster. (At least, that's how I documented it.) I'm not sure how useful the other modes are.