do not try an exponential number of package names
re #11934, and as discussed in the cargo team meeting, this changes the strategy to "the original, all underscore, and all dashes".
I was excessively proud of the `hyphen_combination_num` based implementation when I came up with it. But it's always been a hack. I'm glad to be the one to remove it.
Optimize usage under rustup.
Closes#10986
This optimizes cargo when running under rustup to circumvent the rustup proxies. The rustup proxies introduce overhead that can make a noticeable difference.
The solution here is to identify if cargo would normally run `rustc` from PATH, and the current `rustc` in PATH points to something that looks like a rustup proxy (by comparing it to the `rustup` binary which is a hard-link to the proxy). If it detects this situation, then it looks for a binary in `$RUSTUP_HOME/toolchains/$TOOLCHAIN/bin/$TOOL`. If it finds the direct toolchain executable, then it uses that instead.
## Considerations
There have been some past attempts in the past to address this, but it has been a tricky problem to solve. This change has some risk because cargo is attempting to guess what the user and rustup wants, and it may guess wrong. Here are some considerations and risks for this:
* Setting `RUSTC` (as in https://github.com/rust-lang/rustup/pull/2958) isn't an option. This makes the `RUSTC` setting "sticky" through invocations of different toolchains, such as a cargo subcommand or build script which does something like `cargo +nightly build`.
* Changing `PATH` isn't an option, due to issues like https://github.com/rust-lang/rustup/issues/3036 where cargo subcommands would be unable to execute proxies (so things like `+toolchain` shorthands don't work).
* Setting other environment variables in rustup (as in https://github.com/rust-lang/rustup/pull/3207 which adds `RUSTUP_TOOLCHAIN_DIR` the path to the toolchain dir) comes with various complications, as there is risk that the environment variables could get out of sync with one another (like with `RUSTUP_TOOLCHAIN`), causing tools to break or become confused.
There was some consideration in that PR for adding protections by using an encoded environment variable that could be cross-checked, but I have concerns about the complexity of the solution.
We may want to go with this solution in the long run, but I would like to try a short term solution in this PR first to see how it turns out.
* This won't work for a `rustup-toolchain.toml` override with a [`path`](https://rust-lang.github.io/rustup/overrides.html#path) setting. Cargo will use the slow path in that case. In theory it could try to detect this situation, which may be an exercise for the future.
* Some build-scripts, proc-macros, or custom cargo subcommands may be doing unusual things that interfere with the assumptions made in this PR. For example, a custom subcommand could call a `cargo` executable that is not managed by rustup. Proc-macros may be executing cargo or rustc, assuming it will reach some particular toolchain. It can be difficult to predict what unusual ways cargo and rustc are being used. This PR (and its tests) tries to make extra sure that it is resilient even in unusual circumstances.
* The "dev" fallback in rustup can introduce some complications for some solutions to this problem. If a rustup toolchain does not have cargo, such as with a developer "toolchain link", then rustup will automatically call either the nightly, beta, or stable cargo if they are available. This PR should work correctly, since rustup sets the correct `RUSTUP_TOOLCHAIN` environment variable for the *actual* toolchain, not the one where cargo was executed from.
* Special care should be considered for dynamic linking. `LD_LIBRARY_PATH` (linux), `DYLD_LIBRARY_PATH` (macos), and `PATH` (windows) need to be carefully set so that `rustc` can find its shared libraries. Directly executing `rustc` has some risk that it will load the wrong shared libraries. There are some mitigations for this. macOS and Linux use rpath, and Windows looks in the same directory as `rustc.exe`. Also, rustup configures the dyld environment variables from the outer cargo. Finally, cargo also configures these (particularly for the deprecated compiler plugins).
* This shouldn't impact installations that don't use rustup.
* I've done a variety of testing on the big three platforms, but certainly nowhere exhaustive.
* One of many examples is making sure Clippy's development environment works correctly, which has special requirements for dynamic linking.
* There is risk about future rustup versions changing some assumptions made here. Some assumptions:
* It assumes that if `RUSTUP_TOOLCHAIN` is set, then the proxy *always* runs exactly that toolchain and no other. If this changes, cargo could execute the wrong version. Currently `RUSTUP_TOOLCHAIN` is the highest priority [toolchain override](https://rust-lang.github.io/rustup/overrides.html) and is fundamental to how toolchain selection becomes "sticky", so I think it is unlikely to change.
* It assumes rustup sets `RUSTUP_TOOLCHAIN` to a value that is exactly equal to the name of the toolchain in the `toolchains` directory. This works for user shorthands like `RUSTUP_TOOLCHAIN=nightly`, which gets converted to the full toolchain name. However, it does not work for `path` overrides (see above).
* It assumes the `toolchains` directory layout is always `$RUSTUP_HOME/toolchains/$TOOLCHAIN`. If this changes, then I think the only consequence is that cargo will go back to the slow path.
* It assumes downloading toolchains is not needed (since cargo running from the toolchain means it should already be downloaded).
* It assumes there is no other environment setup needed (such as the dyld paths mentioned above).
My hope is that if assumptions are no longer valid that the worst case is that cargo falls back to the slow path of running the proxy from PATH.
## Performance
This change won't affect the performance on Windows because rustup currently alters PATH to point to the toolchain directory. However, https://github.com/rust-lang/rustup/pull/3178 is attempting to remove that, so this PR will be required to avoid a performance penalty on Windows. That change is currently opt-in, and will likely take a long while to roll out since it won't be released until after the next release, and may be difficult to get sufficient testing.
I have done some rough performance testing on macOS, Windows, and Linux on a variety of different kinds of projects with different commands. The following attempts to summarize what I saw.
The timings are going to be heavily dependent on the system and the project. These are the values I get on my systems, but will likely be very different for everyone else.
The Windows tests were performed with a custom build of rustup with https://github.com/rust-lang/rustup/pull/3178 applied and enabled (stock rustup shows no change in performance as explained above).
The data is summarized in this spreadsheet: https://docs.google.com/spreadsheets/d/1zSvU1fQ0uSELxv3VqWmegGBhbLR-8_KUkyIzCIk21X0/edit?usp=sharing
`hello-world` has a particularly large impact of about 1.68 to 2.7x faster. However, a large portion of this overhead is related to running `rustc` at the start to discover its version and querying it for information. This is cached after the first run, so except for first-time builds, the effect isn't as noticeable. The "check with info" row is an benchmark that removes `target/debug/deps` but keeps the `.rustc_info.json` file.
Incremental builds are a bit more difficult to construct since it requires customizing the commands for each project. I only did an incremental test for cargo itself, running `touch src/cargo/lib.rs` and then `cargo check --lib`.
These measurements excluded the initial overhead of launching the rustup proxy to launch the initial cargo process. This was done just for simplicity, but it makes the test a little less characteristic of a typical usage, which will have some constant overhead for running the proxy.
These tests were done using [`hyperfine`](https://crates.io/crates/hyperfine) version 1.16.1. The macOS system was an M2 Max (12-thread). The Windows and Linux experiments were run on a AMD Ryzen Threadripper 2950X (32-thread). Rust 1.68.2 was used for testing. I can share the commands if people want to see them.
support for shallow clones and fetches with `gitoxide`
This PR makes it possible to enable shallow clones and fetches for git dependencies and crate indices independently with the `-Zgitoxide=fetch,shallow_deps` and `-Zgitoxide=fetch,shallow_index` respectively.
### Tasks
* [x] setup the shallow option when fetching, differentiated by 'registry' and 'git-dependency'
* [x] validate registries are cloned shallowly *and* fetched shallowly
* [x] validate git-dependencies are cloned shallowly *and* fetched shallowly
* [x] a test to show what happens if a shallow index is opened with `git2` (*it can open it and fetch like normal, no issues*)
* [x] assure that `git2` can safely operate on a shallow clone - we unshallow it beforehand, both for registries and git dependencies
* [x] assure git-deps with revisions are handled correctly (they should just not be shallow, and they should unshallow themselves if they are)
* [x] make sure shallow index clones aren't seen by older cargo's
* [x] make sure shallow git dependency clones aren't seen by older cargo's
* [x] shallow.lock test and more test-suite runs with shallow clones enabled for everything
* [x] release new version of `gix` with full shallow support and use it here
* [x] check why `shallow` files remain after unshallowing. Should they not rather be deleted if empty? - Yes, `git` does so as well, implemented [with this commit](2cd5054b0a)
* ~~see if it can be avoided to ever unshallow an existing `-shallow` clone by using the right location from the start. If not, test that we can go `shallow->unshallow->shallow` without a hitch.~~ Cannot happen anymore as it can predict the final location perfectly.
* [x] `Cargo.lock` files don't prevent shallow clones
* [x] assure all other tests work with shallow cloning enabled (or fix the ones that don't with regression protection)
* [x] can the 'split-brain' issue be solved for good?
### Review Notes
* there is a chance of 'split brain' in git-dependencies as the logic for determining whether the clone/fetch is shallow is repeated in two places. This isn't the case for registries though.
### Notes
* I am highlighting that this is the `gitoxide` version of shallow clones as the `git2` version [might soon be available](https://github.com/libgit2/libgit2/pull/6396) as well. Having that would be good as it would ensure interoperability remains intact.
* Maybe for when `git2` has been phased out, i.e. everything else is working, I think (unscientifically) there might be benefits in using worktrees for checkouts. Admittedly I don't know the history of why they weren't used in the first place. Also: `gitoxide` doesn't yet support local clones and might not have to if worktrees were used instead.
Doing so seems cleaner as there should be no logical difference between
shallow or not-shallow when fetching. We want a specific object, and should
get it with the refspec. `git` will assure we see all objects we need,
handling shallow-ness for us.
Note that one test needed adjustments due to the different mechanism used
when fetching local repositories, requiring more changes to properly 'break'
the submodule repo when `gitoxide` is used.
cargo-tree: Handle -e no-proc-macro when building the graph
### What does this PR try to resolve?
Makes `-e no-proc-macro` more useful when combined with `-i` or `-d`. Fixes#12030.
### How should we test and review this PR?
The new and existing tests should cover this, I hope!
### Additional information
Pruning proc-macro crates during graph construction is closer to how the edge-based filters work (`[no-]build` etc.), so even though `no-proc-macro` isn't technically filtering on edges, it's following a well-established code path.
This is an improvement over the previous version which would use unshallowing that effectively
makes a shallow repo *not* shallow.
Furthermore, we will now only fetch a single commit, each time we fetch, which should be faster
for the server as well as for the client.
We also make it possible to fetch individual commits that would be specified via Cargo.lock.
A couple of test expectations are adjusted accordingly.
Is this desirable behaviour? Unfortunately, there is no alternative
as adding shallow to an existing index most definitely breaks backwards
compatibility.
The implementation hinges on passing information about the kind of clone
and fetch to the `fetch()` method, which then configures the fetch accordingly.
Note that it doesn't differentiate between initial clones and fetches as
the shallow-ness of the repository is maintained nonetheless.
crates.io reads rust-version from the tarball directly, but we can include it in
the publish request for the sake of consistency for third-party registries.
The headers can significantly contribute to noise in the output,
drowning out the rest of the output. Most investigation will likely be
focused on the case where cargo completely fails to download, so this
only shows the full detail in the final error message.
Use registry.default for login/logout
This changes `cargo login` and `cargo logout` to use the registry configured at `registry.default` as the registry instead of crates.io. For `cargo login`, this was an unintentional regression from #6466. The documentation has always stated that it will use the default registry.
This makes the command more in line with other registry-involving commands. There are still some inconsistencies.
These commands use the default if not specified:
* `cargo init`
* `cargo new`
* `cargo owner`
* `cargo search`
* `cargo yank`
* `cargo publish` uses the default, but will also look at the `publish` field `Cargo.toml` and use that if the registry is not specified.
These commands would always use crates.io if `--registry` is not specified:
* `cargo login`
* `cargo logout`
* `cargo install`
I'm a bit uncertain how to proceed, since this is technically a breaking change particularly if someone has scripted it. I suspect that the number of users that use `registry.default` is very small, and those that script `cargo login` are even smaller, and thus the intersection is probably small or nonexistent. However, there is some risk here.
Rustc supports these since rust-lang/rust#109808. It's technically
possible to set a named debuginfo level through `RUSTFLAGS`, but in
practice cargo always passes its own opinion of what the debuginfo level
is, so allow it to be configured through cargo too.
Fix credential token format validation.
The existing validation incorrectly excluded tab because of a missing backslash. This updates to add the backslash.
This also rewords the comments. I found the current comments to be a little confusing.
This also extends the test to verify more valid inputs.
cc #11600
When doing a credential lookup, Cargo deserializes the registry configuration and detects the
registries.crates-io.protocol key as unused and issues a warning.
This fixes the issue by adding the field to the struct
Add delays to network retries.
This adds a delay to network retries to help guard against short-lived transient errors.
The overview of how this works is: Requests that fail are placed into a queue with a timestamp of when they should be retried. The download code then checks for any requests that need to be retried, and re-injects them back into curl.
Care must be taken in the download loops to track which requests are currently in flight *plus* which requests are waiting to be retried.
This also adds jitter to the retry times so that multiple failed requests don't all flood the server when they are retried. This is a very primitive form of jitter which suffers from clumping, but I think it should be fine.
The max number of retries is raised to 3 in order to bring the total retry time to around 10 seconds. This is intended to address Cloudfront's default negative TTL of 10 seconds. The retry schedule looks like 0.5seconds ± 1 second, then 3.5 seconds then 6.5 seconds, for a total of 10.5 to 11.5 seconds. If the user configures additional retries, each attempt afterwards has a max delay of 10 seconds.
The retry times are currently not user-configurable. This could potentially be added in the future, but I don't think is particularly necessary for now.
There is an unfortunate amount of duplication between the crate download and HTTP index code. I think in the near future we should work on consolidating that code. That might be challenging, since their use patterns are different, but I think it is feasible.
Handle case mismatches when looking up env vars in the Config snapshot
### What does this PR try to resolve?
Fixes#11814.
Windows environment variables are case-insensitive, which causes problems when looking them up in the `Config` env snapshot.
This PR adds another member (`case_insensitive_env`) in `Config` that maps upper-cased keys to their original values in the env (for example, `"PATH" => "Path"`). If lookup in `self.env` fails, this PR converts the key to upper case and looks it up in `self.case_insensitive_env` to obtain the correct key name if it exists (on Windows only).
### How should we test and review this PR?
Please see the new tests in `testsuite/config.rs` and `testsuite/cargo_command.rs`.
### Additional information
Currently, this uses `str::to_uppercase` to uppercase the keys. This requires key to be valid UTF-8, and may disagree with how the OS uppercases things (see the link in [this comment](https://github.com/rust-lang/cargo/issues/11814#issuecomment-1462870983) for details).
align semantics of generated vcs ignore files
### What does this PR try to resolve?
The currently generated `^target/` spec in a hg ignore will only ignore dirs of that name at the root.
This change matches the behavior of the gitignore spec next to it, by only ignoring both files/symlinks and dirs of name "target".
### How should we test and review this PR?
Run `cargo new`
Accurately show status when downgrading dependencies
### What does this PR try to resolve?
A few times now I've ran into issues where Cargo ends up downgrading a dependency in order to satisfy a pinned dependency somewhere in the dependency graph. Unfortunately this is not clear in the output of `cargo update`, which just shows all the changed dependencies as `Updating`.
References:
* #5702
* [Finding a pinned dependency edge](https://users.rust-lang.org/t/finding-a-pinned-dependency-edge/81157)
* https://github.com/tokio-rs/axum/issues/1814
### How should we test and review this PR?
This is a small change that tries to make dependency downgrades stand out more in the output of `cargo update`. I have not added any new tests since the existing tests seem to cover this functionality.
Some tests still fail, these refer to Git dependencies. I'm honestly not sure how to handle these, so I'd like to get some feedback on this before I fix those tests up. Git commits form a DAG, so one option is to see if the new commit is an ancestor of the old one (mark as "updating"), if the old commit is an ancestor of the new one (mark as "downgrading"), or neither (could be from parallel branches) we could compare based on timestamp in that case.
### To do
* Fix up tests for Git dependency updates
The proper fix is in https://github.com/Byron/gitoxide/releases/tag/gix-v0.41.0
which unfortunately can't be used as it also comes with the latest `tempfile` v3.4
which causes other issues when compiling on some platforms.
Thus we first disable the flaky tests, and re-enable them with the `gix` upgrade
which should be possible once `tempfile` doesn't hinder `cargo` on some platforms
anymore.
Related to https://github.com/rust-lang/cargo/issues/11821
Add `CARGO_PKG_README`
Fixes#11597
This environment variable shows the path to the README file of your package. From #11597:
> Cargo may rewrite the package’s `Cargo.toml` and move the README file around, relative to the manifest. I would like to `include_str!()` this README in my `lib.rs`, but am unable to do so right now, because if I specify `include_str!("../../README")` it works for development, but I can’t package my crate. Conversely if I specify `include_str!("../README")` it works when packaged, but not during development.
Adding display of which target failed to compile
Closes#10834
Attached example.zip is the same as the one mentioned on the issue. You could use it to test the fix by using the new built cargo:
```./cargo build --manifest-path C:\Rust\example_cargo_error\Cargo.toml```
Before fixing:
```
error: could not compile `example` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
```
After fixing:
```
error: could not compile `example` (build script) due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
```
[example.zip](https://github.com/rust-lang/cargo/files/10522342/example.zip)
Fix `CARGO_CFG_` vars for configs defined both with and without value
When a rustc cfg is defined both with and without value, the environment variable should provide all the values. Before this change, it ended up being empty.
Fixes: #11789
When a rustc cfg is defined both with and without value, the
environment variable should provide all the values. Before this change,
it ended up being empty.
Fixes: #11789
Make `sparse` the default protocol for crates.io
Changes the default protocol for accessing crates.io to `sparse`.
The protocol can be switched back to `git` via the configuration key `registries.crates-io.protocol` = `git`
Closes#10965
This allows to use `gitoxide` for all fetch operations, boosting performance
for fetching the `crates.io` index by a factor of 2.2x, while being consistent
on all platforms.
For trying it, nightly builds of `cargo` can specify `-Zgitoxide=fetch`.
It's also possible to set the `__CARGO_USE_GITOXIDE_INSTEAD_OF_GIT2=1` environment
variable (value matters), which is when `-Zgitoxide=none` can be used
to use `git2` instead.
Limitations
-----------
Note that what follows are current shortcomings that will be addressed in future PRs.
- it's likely that authentication around the `ssh` protocol will work differently in practice
as it uses the `ssh` program.
- clones from `file://` based crates indices will need the `git` binary to serve the locatl repository.
- the progress bar shown when fetching doesn't work like the orgiinal, but should already feel 'faster'.
patch can conflict on not activated packages
### What does this PR try to resolve?
In the resolver there is a data structure called a `conflicting_activations`, which records all the reasons a "better" version was not picked for the package being resolved. Normally, these are packages that are currently active that for one reason or another block one of the other versions. Several optimizations assumed that this was always true, even going so far as to use `.expect`. This was a mistake because when there's a `patch` involved there can be conflicts on a version that is not selected. So the correct behavior is to fall back to skip the optimizations and try all versions when a `conflicting_activations` are not active.
### How should we test and review this PR?
This adds two automated tests based on the reproductions in #7463 and #11336. So the test suite now covers this case. It can also be tested by reconstructing the repositories originally reported in those issues.
### Additional information
It could be that in the long term the correct fix is to figure out how to support patch without having a conflicting activation that is not activated. But that would be a much bigger change. And for now this assumption is only used in optimizations, so this gets people unstuck.
fix(toml): Provide a way to show unused manifest keys for dependencies
Dependencies have not been able to show unused manifest keys for some time, this problem partially resulted in #11329.
This problem is caused by having an `enum` when deserializing. To get around this you can use:
```rust
#[serde(flatten)]
other: BTreeMap<String, toml::Value>,
```
This collects any unused keys into `other` that can later be used to show warnings. This idea was suggested in a thread I cannot find but is mentioned in [serde#941](https://github.com/serde-rs/serde/issues/941).
Improve error for missing crate in --offline mode for sparse index
This changes sparse registries to instead return `NotFound` when a non-cached crate is requested in `--offline` mode.
The resolver can then suggest removing the `--offline` flag if resolution fails, which is a more helpful error than the one currently issued: `attempting to make an HTTP request, but --offline was specified`.
With this change, the behavior matches what is already done for git-based registries.
Closes#11276
This changes sparse registries to instead return not found when a non-cached crate is requested in offline mode.
The resolver can then suggest removing the --offline flag if resolution
fails.
feat(resolver): `-Zdirect-minimal-versions`
This is an alternative to `-Zminimal-versions` as discussed in #5657.
Problems with `-Zminimal-versions` includes
- Requires the root most dependencies to verify it and we then percolate that up the stack. This requires a massive level of cooperation to accomplish and so far there have been mixed results with it to the point that cargo's unstable
documentation discourages its use.
- Users expect `cargo check -Zminimal-versions` to force resolving to minimal but it doesn't as the default maximal resolve is compatible and requires `cargo update -Zminimal-versions`
- Different compatible versions might be selected, breaking interop between crates, changing feature unification, and breaking `-sys` crates without bad `links`
`-Zdirect-minimal-versions` instead only applies this rule to your
direct dependencies, allowing anyone in the stack to immediately adopt
it, independent of everyone else.
Special notes
- Living up to the name and the existing design, this ignores yanked
crates. This makes sense for `^1.1` version requirements but might
look weird for `^1.1.1` version requirements as it could select
`1.1.2`.
- This will error if an indirect dependency requires a newer version.
Your version requirement will need to capture what you use **and** all
of you dependencies. An alternative design would have tried to merge
the result of minimum versions for direct dependencies and maximum
versions for indirect dependencies. This would have been complex and
led to weird corner cases, making it harder to predict. I also suspect
the value gained would be relatively low as you can't verify that
version requirement in any other way.
- This also means discrepancies between `dependencies` and `dev-dependencies` are errors
- The error could be improved to call out that this was from minimal
versions but I felt getting this out now and starting to collect
feedback was more important.
One advantage of this approach over `-Zminimal-versions` is that it removes most of the problems that [cargo-minimal-versions](https://github.com/taiki-e/cargo-minimal-versions) tried to workaround.
As for the implementation, this might not be the most elegant solution but it works and we can always iterate and improve on it in the future.
- We keep the state as a `bool` throughout but compensate for that by explicitly creating a variable to abstract away constants
- The name changes depending on the context, from `direct_minimal_version` when dealing with the unstable flag to `first_minimal_version` when the concept of "direct" is lost to `first_version` when we split off the ordering concept into a separate variable
- Packages that respect `direct_minimal_versions` are determined by whether they are the top-level `summaries` that get past into `resolve`
### What does this PR try to resolve?
The primary use case is verifying version requirements to avoid depending on something newer than might be available in a dependent
For this to help the MSRV use case, the crate author must directly depend on all indirect dependencies where their latest release has too new of an MSRV but at least they can do so with the `^` operator, rather than `<` and breaking the ecosystem.
### How should we test and review this PR?
The first two commits add tests using `-Zminimal-versions`. The commit that adds `-Zdirect-minimal-versions` updates the tests, highlighting the differences in behavior.
### Additional information
Potential areas of conversation for stablization
- Flag name
- Handling of yanked (pick first non-yanked, pick yanked, error)
- Quality of error message
- Should the package have a "memory" of this flag being set by writing it to the lockfile?
Potential future work
- Stablize this
- Remove `-Zminimal-versions`
- Update `cargo publish`s `--verify` step to use this.
- The challenge is this won't be using the packaged `Cargo.lock` which probably should also be verified.
Error message for transitive artifact dependencies with targets the package doesn't directly interact with
Address #11260. Produces an error message like described by `@weihanglo` [here](https://github.com/rust-lang/cargo/issues/11260#issuecomment-1400455203):
```
error: could not find specification for target "x86_64-windows-msvc"
Dependency `bar v0.1.0` requires to build for target "x86_64-windows-msvc".
```
Note that this is not a complete fix for #11260.
Suggest cargo add when installing library crate
### What does this PR try to resolve?
When using `cargo install` instead of `cargo use` the error message is the following:
```
error: there is nothing to install in `foo v0.0.1`, because it has no binaries
`cargo install` is only for installing programs, and can't be used with libraries.
To use a library crate, add it as a dependency in a Cargo project instead.
```
It would be good to suggest to the user to use `cargo add`.
### How should we test and review this PR?
The `no_binaries` test from `tests/testsuite/install.rs` covers that case.
Switch some tests from `build` to `check`
#11341 brought up issues with cargo's `testsute` size and speed. One of the suggested fixes was switching most tests to `check` instead of `build`. This PR did that.
Before size on `nightly`: 4.4GB
After size on `nightly`: 4.2GB
Regex to find `build` in `tests/testsuite`: `cargo\(".*build.*\)`
Before: 1607
After: 626
Note I did not remove all `build` I only did the easy ones that required minimal changes. I also tried not to touch systems I was unsure about. There could be other uses of `build` I missed as well.
I still need to play around with `opt-level`, `debug=0`, and a few other tweaks, but there should be more time/memory to drop.
Each test file changed is in a commit of its own, so you should look commit by commit.
