Implement some way to run UI tests ignoring run-pass tests

[petrochenkov]

run-pass test were recently merged into UI tests (#53860, #53992, #53994), which is unfortunate in several aspects.

If you are working with diagnostics (changing spans, labels, error messages, etc) or in "compile-fail" area in general, and want to check the result on UI tests, then there's absolutely no need to run thousands of run-pass tests (+ their NLL variations) as well, which are also quite slow because you have to launch both the compiler and the produced executable.

[petrochenkov]

cc @pnkfelix @estebank

[pnkfelix]

• (1a) One option: make a separate ui-run-pass suite and move this stuff there. That is perhaps the simplest to implement, but I don't know if it has the ideal developer UX.
  • (1b) A variant of this: reorganize ui/ to have subdirectories ui/compile-fail/, ui/compile-pass/, ui/run-pass/, ... and then move everything there. Then a developer should be able to opt into the subarea they are interested in, like compile-fail, by specifying it on their command line.
• (2a) Another (orthogonal) option: add a flag that makes compiletest treat // run-pass as if it said // compile-pass. This would resolve the time overhead from running the tests.
  • (2b) A variant of this would provide flags to let the user say things like "only run the // compile-fail tests" or "skip the // run-pass tests...

Of the above choices, I think I like (1b) the best...

---

Anyway, my apologies: My whole strategy of resolving #53764 by migrating the run-pass tests to a subdirectory of ui/ was based on the presumption that the ui tests don't represent a huge part of our autobuild infrastructure overhead. While I did ask the infrastructure team whether this presumption was correct, the whole problem is that that presumption was not sufficient; it considered solely the overhead from our autobuild infrastructure, and failed to consider overall developer UX.

[pnkfelix]

Nominating for discussion at T-compiler meeting.

[pnkfelix]

(actually, after further reflection, I'm starting to warm up to option (1a). After all, we started with a model where we had separate compile-fail and run-pass suites. So it would make sense to retain that division, and just think of this as "upgrading" each of the suites to test the compiler UX as well...)

[petrochenkov]

I remember that @nikomatsakis wanted to avoid variants like 1a/b to introduce a per-feature directory structure instead:

/ui
    /rfc-XXXX-feature-name1
        *both compile-fail and run-pass tests for this feature*
    /rfc-YYYY-feature-name1
        *both compile-fail and run-pass tests for this feature*
    /rfc-ZZZZ-feature-name1
        *both compile-fail and run-pass tests for this feature*

with run-pass/compile-pass/compile-fail discerned by in-file annotations (i.e. like it works right now basically).
With this scheme compiletest/rustbuild would need to regain the ability to run test groups separately, but now using those annotations.

[pnkfelix]

I do notice that compiletest has a --mode argument which is implemented as only accepting one of "(compile-fail|parse-fail|run-fail|run-pass|run-pass-valgrind|pretty|debug-info|incremental|mir-opt)",

I suspect that is implemented by inspecting directory names, but since it does not list ui, we could expand its meaning to also mean "inspect the header of the ui/ tests to determine its catgory." That might give us a straight-forward way to implement option (2b) that I recently added to my comment above.

Update: Oops, the documentation doesn't mention ui, but the implementation does have a Mode::Ui variant, and the impl FromStr for Mode will indeed translate "ui" to Mode::Ui.

Still, I am warming up to this new approach to implementing option (2b).

[nikomatsakis]

My feeling here:

• I dislike dividing up our test suite into directories like run-pass, compile-fail, etc
• I would rather have the "primary organization" of the tests be the area of code that they are testing (e.g., borrowck, regionck, some RFC, etc)

This leads me to suggest that we ought to add a "test filter" that lets you pare down the tests to exclude run-pass or other modes. In fact, if we included the "mode" in the name of the test, that would happen automatically via --test-args, but that might break other things.

e.g., the name of a // run-pass test called foo/bar.rs could be foo/bar.rs (run-pass) or something like that. Then you could do --test-args '(run-pass)'.

(Of course, there really is no ideal way to organize the tests. But organizing by "what the tests are testing" has advantages when you're trying to look over the set of tests for a given feature, and using --test-args to filter seems to fulfill the other use cases. I can't think of a time when I'm like "I'd like to browse the set of tests that don't generate errors".)

[pnkfelix]

discussed at meeting. P-high. I will work on addressing @petrochenkov 's developer UX concern in short term.