Rust: Tracking Issue for moving UI tests for libstd into unit tests

[jyn514]

This is a tracking issue for switching UI tests in src/test/ui which only test the standard library into unit tests.

Rationale

This will:

• Improve compile times for the test suite as a whole, since fewer binaries are being linked and run
• Make it easier to find the code corresponding to a failing test
• Allow running more tests without having to first build the stage1 compiler
• Allow running more tests with miri (https://github.com/RalfJung/miri-test-libstd)

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Mentoring instructions (or rather, suggested workflow for contributors)

Please first leave a comment here stating that you want to work on file xxx.rs or module xxx, to make sure that this implements Sync.

1. Find a test in src/test/ui that has both // run-pass and a use of the standard library. The test also cannot use //~ WARN or any other error annotations, since that is not supported by #[test]. For more information about annotations see https://rustc-dev-guide.rust-lang.org/tests/adding.html#header_commands; if there is an annotation on the test that can't be replicated with #[test] or #[cfg(...)], feel free to skip it.

rg run-pass src/test/ui -l | xargs rg '(std|alloc|core)::' -l | xargs rg -v 'WARN' -l

1. Move the test into the relevant part of library/. Add a #[test] annotation so it will be run by x.py test library/std. Make sure that it is actually being run - you can be sure by running x.py test --stage 0 library/std --test-args name_of_the_new_test and seeing at least one test run.

If it is unclear whether run-pass exercises standard library or a particular facet of the compiler, you can look at the PR/commit that introduced the test. If it was introduced together with the stdlib API it exercises, then it definitely belongs to library/.

Implementation history

• #76273 is a good first example

For other candidates, see, for example, the tests in https://github.com/rust-lang/rust/blob/master/src/test/ui/consts/std/net/ipv6.rs.

Mentoring instructions for reviewers

I highly recommend git show -w --reverse --color-moved=dimmed-zebra --color-moved-ws=allow-indentation-change <base>.., where <base> is git merge-base origin/master <tip commit> and <tip commit> is the head of the branch.

@matklad has volunteered to review PRs implementing this. Add r? @matklad to the PR description to automatically assign review to them.

[RalfJung]

This is a tracking issue for switching UI tests in src/test/ui which only test the standard library into unit tests.
This will improve compile times, as well as make it easier to find the code corresponding to a failing test.

This will also help https://github.com/RalfJung/miri-test-libstd which only runs unit tests, not UI tests. So, we'll have better Miri libstd test coverage. :)

[poliorcetics]

Where do I put the tests in src/test/ui/bool.rs ? All the imported types belong to core but I'm not sure where to move the tests (or even if they should be moved ?)

[jyn514]

Where do I put the tests in src/test/ui/bool.rs ? All the imported types belong to core but I'm not sure where to move the tests (or even if they should be moved ?)

I see a library/std/tests/bool.rs, maybe there?

[poliorcetics]

Should tests like src/test/ui/borrowck/borrowck-univariant-enum.rs be ported ? It has no special attributes but I don't think porting it to the Cell tests is appropriate either.

As a whole, the tests about async-await and borrow-ck are numerous and probably slow compilation down somewhat but I don't know where else to put them.

[workingjubilee]

I looked for the wrong tag to find this issue so I'm adding it, I guess?
@rustbot modify labels: +C-cleanup

[workingjubilee]

@poliorcetics Tests that are using std to test rustc are a different question than tests that directly and obviously concern using std to test std. They probably _can_ be cleaned up, but I don't think you should worry about them for now if they're primarily concerned with things like borrowck or async/await syntax. They can be reviewed as part of another pass.

[workingjubilee]

The advice to add a UI test by default should be qualified slightly with more guidance under https://rustc-dev-guide.rust-lang.org/tests/adding.html#what-kind-of-test-should-i-add in order to stem the tide further.