Fix 'getting started' internal links
Currently the internal links do not work, the path is incorrect.
Update the path for internal links in the index file of 'getting started' section thereby fixing the links generated in HTML.
Currently the internal links do not work, the path is incorrect.
Update the path for internal links in the index file of 'getting started'
section thereby fixing the links generated in HTML.
improve uncommitted changes cargo-package message
fixes#7003
Explicitly state what the suggested flag `--allow-dirty`
actually does when packaging/publishing the crate. Primarily,
that the uncommitted changes are included within the resulting
package.
fixes#7003
Explicitly state what the suggested flag `--allow-dirty`
actually does when packaging/publishing the crate. Primarily,
that the uncommited changes are included within the resulting
package.
Clean environment when git-fetch-with-cli is used.
When the GIT_DIR environment variable is set, git-the-cli will use that instead of looking at cwd. This can happen, for example, when using the `exec` command in `git rebase` to call cargo. This causes cargo to fetch into the wrong directory.
Closes#7072
Fix exponentiality in depend_on_deps_of_deps.
With `CARGO_BUILD_PIPELINING=true`, cargo was spending a long time (15 seconds) before starting any compilation. That is caused by a naive graph traversal in `depend_on_deps_of_deps`. Instead, let's make sure not to keep traversing the same deps. With this patch, things are fast again.
_cargo: Make function style consistent
They are just white-space changes. I'm planning to bring back Zsh completion
for `-p` (package) option, which was disabled in #1713. This PR is the first
stepping stone towards that goal.
A disadvantageous is that I am just starting to learn Zsh completion system.
Guess how far can I go?
r? @ehuss
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.
