Description
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 mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- 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.