Add attribute to run specific tests in an isolated process

Proposal

Assuming that#[deprecated_safe] is accepted and applied to env::set_var/env::remove_var, there will need to be some way for unit tests to be made sound if they call the now unsafe env::set_var/env::remove_var. This can be done by guaranteeing that specific tests are started with only a single thread active, and then each affected test can ensure it meets the safety precondition of env::set_var/env::remove_var that no other threads could be reading or writing the environment.

To guarantee specific tests are started with only a single thread active, a new attribute is added that can be applied to #[test] items. This will cause each marked test to be run in its own isolated process, with a single thread guaranteed to be active when the #[test] item is entered. A new process is needed for each test, rather than running marked tests one after another in a single thread, as a prior test may have spun up background threads.

Proof of concept implementation that piggybacks off the functionality already present for -Zpanic-abort-tests.

Some additional motivations from the zulip stream, unrelated to env::set_var/env::remove_var:

• heap usage testing ... how to write these tests so they don't interfere with each other or the test harness
• it would also be useful for various other std tests, e.g. testing fork, chdir and similar things

Concerns from zulip:

• one concern I have here is Miri compatibility
• I don't feel like improving the built-in test framework little-by-little this way is going to produce a consistent, full-featured experience

Alternatives from zulip:

• I hope at some point we will get custom test runners / we already have an unstable way for custom test runners

Mentors or Reviewers

If you have a reviewer or mentor in mind for this work, mention then
here. You can put your own name here if you are planning to mentor the
work.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[nikomatsakis]

@rustbot label +I-lang-nominated

Nominating for @rust-lang/lang discussion--this too feels like a language change to me.

[joshtriplett]

We discussed this in today's @rust-lang/lang meeting, and we were generally fine with adding this. We'd like to have a lang FCP before this is stabilized. We don't see any reason to block experimentation in this area.

[pnkfelix]

@rustbot second

[pnkfelix]

(I'm seconding to try to push for us to move forward on adding this as an unstable feature. I assume that both T-compiler and T-lang will be included in an FCP as part of eventual stabilization on rust-lang/rust itself.)

[apiraino]

@rustbot label -final-comment-period +major-change-accepted