Fix nonconcurrent tests

[jethrogb]

The cargo testsuite relies on a clean test “root” for every test (i.e. #[test]-annotated function). It relied on the test crate's behavior to spawn a new thread for each test, which isn't done when tests aren't run concurrently, breaking the test suite. In this PR, I'm using backtraces to figure out which test is being run, which is much more robust. I also cleaned up the root initialization logic so that it no longer recursive calls the init function.

Fixes #6746

[rust-highfive]

r? @ehuss

(rust_highfive has picked a reviewer for you, use r? to override)

[jethrogb]

Ping @ehuss

[ehuss]

Thanks for the PR! I don't think we can use backtraces to detect the current test, though. For example, on mac it runs about 5 times slower than normal.

Would you be willing to try a solution that involves creating a new proc-macro attribute? I think this should work: Create a new #[cargo_test] attribute which replaces the existing #[test] attribute. It should add a #[test] attribute, and also add a call to an initialization function at the top of the test. This initialization function can then use thread-local data to determine if it is a new test or not, and store the appropriate thread-local TASK_ID.

[jethrogb]

Done. I've put all the attribute changes in a separate commit for the reviewer's benefit.

[ehuss]

Would it be possible to keep the attribute short, like #[cargo_test]? What I was thinking is that the attribute would inject a call to an initialization function at the top of the test, and then remove the call to init from paths::root. This should ensure the test is only initialized once, and only for that test. The init function would need to check a thread-local value to determine if it is a new test, or if it is a test reusing a thread (in which case an new ID would be issued). Also, keeping the project named cargo_test would make its intent clearer if/when adding other macros.

[jethrogb]

Would it be possible to keep the attribute short, like #[cargo_test]?

I wanted to keep the proc_macro hygenic. If you don't think that's useful, that can be done.

What I was thinking is that the attribute would inject a call to an initialization function at the top of the test, and then remove the call to init from paths::root. This should ensure the test is only initialized once, and only for that test. The init function would need to check a thread-local value to determine if it is a new test, or if it is a test reusing a thread (in which case an new ID would be issued).

This is possible but it's a pretty significant rewrite of what I've done so far for IMO very little gain. Are you worried about the perf of the Mutex?

[bors]

☔ The latest upstream changes (presumably #6883) made this pull request unmergeable. Please resolve the merge conflicts.

[ehuss]

I wanted to keep the proc_macro hygenic. If you don't think that's useful, that can be done.

I don't know what this means here. I'm not sure how injecting a call to an init function should affect hygene.

Are you worried about the perf of the Mutex?

Well, this as-is doesn't work. I'm not sure, but it looks to have some race conditions. I would lean towards a simple solution, more analogous to traditional test suite "setup" functions, that gets run before the test starts.

[jethrogb]

I don't know what this means here. I'm not sure how injecting a call to an init function should affect hygene.

The init function is not defined by the proc macro, so if you don't pass in the path to the init function, the macro is just making up the path out of thin air, which may or may not be imported at the place the function is defined.

Well, this as-is doesn't work. I'm not sure, but it looks to have some race conditions.

I think it works fine, and there's no opportunity for a race condition because mostly everything is thread-local. The tests are currently failing because I think I changed some #[test] attributes that were inside the test cases.

[jethrogb]

@ehuss I answered your questions.

[ehuss]

I would still prefer a simpler attribute as explained above.

Also, I don't think we can't switch Cargo to a workspace because it is inside another workspace in rust-lang.

EDIT: We'll also need to figure out some way to publish this new package, we can't have a path-only dependency. My preference would be to relax this restriction, but it'll be some work.

[jethrogb]

Pushed changes. If the current code is acceptable I'd prefer a swift review since this bitrots pretty quickly.

[ehuss]

Thanks!
I rebased and included some updates to make it publishable.
@bors r+

[bors]

📌 Commit a8c22ca has been approved by ehuss

[bors]

⌛ Testing commit a8c22ca with merge d5723eb...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: ehuss
Pushing d5723eb to master...

[Eh2406]

I am seeing thread 'publish_lockfile::note_resolve_changes' panicked at 'path.metadata() failed with The system cannot find the file specified. (os error 2)', tests\testsuite\support\paths.rs:197:25 and then all other tests are failing with thread 'registry::resolve_and_backtracking' panicked at 'Once instance has previously been poisoned', src\libstd\sync\once.rs:362:21

[jethrogb]

Can you run it again with RUST_BACKTRACE=1?

[Eh2406]

Looks like delling my cit folder fixed the problem. Sorry for the noize.

[ehuss]

@Eh2406 I'm having a hard time reproducing the issue you are seeing. I had a few questions:

• Does it get stuck permanently? That is, every time you run cargo test it fails until you manually delete cit?
• Have you figured out a way to reliably cause it to happen? If so, can you list the exact steps?
• Are you just running cargo test, or are you giving other flags?
• If you can recreate it, can you modify the do_op function to print which file it is trying to delete?
• Is there anything unusual about your system? Is it running Defender or any other AV? Are you using an editor or IDE that might be indexing the target directory? Do you have an SSD?

[ehuss]

Oh, I reproduced it! I think lowering down to 2 cpu's was the trick.

I'll dig in a little more.