Stabilize default-run
This stabilizes the default-run feature.
I've included some error message changes. If `default-run` specifies an unknown binary, it now tells you that the `default-run` field is incorrect and which manifest it is located in, instead of just saying "could not determine which binary to run".
I also consolidated some of the suggestion code so it is not repeated all over.
Closes#7032
Now that the `mtime` of intermediate artifacts is not updated there's no need
for this test anymore (it now fails because without the `mtime`s it cannot
perform the intended GC operation).
Resolver test/debug cleanup
This is several small things salvaged from abandoned PRs and implemented on top of #7011
In working on this I noted that the prop tests are very sensitive to whether backtrace are turned on. Maybe we should set that env to 0 for that builder?
Revert test directory cleaning change.
#6900 changed it so that the entire `cit` directory was cleaned once when tests started. Previously, each `t#` directory was deleted just before each test ran. This restores the old behavior due to problems on Windows.
The problem is that the call to `rm_rf` would fail with various errors ("Not found", "directory not empty", etc.) if you run `cargo test` twice. The first panic would poison the lazy static initializer, causing all subsequent tests to fail.
There are a variety of reasons deleting a file on Windows is difficult. My hypothesis in this case is that services like the indexing service and Defender swoop in and temporarily hold handles to files. This seems to be worse on slower systems, where presumably these services take longer to process all the files created by the test suite. It may also be related to how files are "marked for deletion" but are not immediately deleted.
The solution here is to spread out the deletion over time, giving Windows more of an opportunity to release its handles. This is a poor solution, and should only help reduce the frequency, but not entirely fix it.
I believe that this cannot be solved using `DeleteFileW`. There are more details at https://github.com/rust-lang/rust/issues/29497, which is a long-standing problem that there are no good Rust implementations for recursively deleting a directory.
An example of something that implements a "safe" delete is [Cygwin's unlink implementation](ad101bcb0f/winsup/cygwin/syscalls.cc (L675-L1064)). As you can see, it is quite complex. Of course our use case does not need to handle quite as many edge cases, but I think any implementation is going to be nontrivial, and require Windows-specific APIs not available in std.
Note: Even before #6900 I still get a lot of errors on a slow VM (particularly "directory not empty"), with Defender and Indexing off. I'm not sure why. This PR should make it more bearable, though.
Extract resolver tests to their own crate
These tests take a good amount of time to run locally and they're also
causing a lot of dependencies to get pulled into rust-lang/rust, so
let's have a separate crate that we just test on our own CI
These tests take a good amount of time to run locally and they're also
causing a lot of dependencies to get pulled into rust-lang/rust, so
let's have a separate crate that we just test on our own CI
Support absolute paths in dep-info files
These changes are a little more invasive then I would've liked, but I couldn't come up with a significantly better way to structure this. Comments (or backwards-compat) concerns are appreciated, of course!
cc https://github.com/rust-lang/rust/pull/61727
r? @alexcrichton
rustc wants to provide sysroot dependencies and perhaps eventually
statically/dynamically linked C libraries discovered in library serach
paths to Cargo. Mostly this is only useful today for rustbuild as
otherwise Cargo's assumption that the sysroot is only changed if `rustc`
itself changes is pretty much always correct.
Stabilize publish-lockfile.
This stabilizes the publish-lockfile feature. Specifically:
- Makes `Cargo.lock` included by default for packages with executables.
- Deprecates the `publish-lockfile` manifest key. It is no longer used.
Additional notes:
- Fixed issue where if a `Cargo.lock` file didn't exist, `cargo package` would fail the
VCS dirty check.
- Changed it so that `cargo publish` or `cargo package` will now show manifest
warnings. I believe this was an oversight.
Closes#5654
change package cache lock message
Change the message from
waiting for file lock on package cache lock
to
waiting for file lock on package cache
The former message made it sound like the lock itself had a lock.
Fix nonconcurrent tests
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
