Homepage doc cargo metadata
Adds two new field to cargo-metadata: `homepage` and `documentation`, lifted directly from the Cargo.toml. This additionally makes those fields available through `cargo read-manifest`.
Correct mistake about supporting sub-makes and document CARGO_MAKEFLAGS
Sub-makes are currently not supported as the jobserver crate only
sets CARGO_MAKEFLAGS which GNU Make doesn't understand.
This might be reasonable as cargo overriding existing MAKEFLAGS
variables would be weird, but also makes the statement in the
reference false.
It's helpful for build script authors who want to invoke make
to know how to get make subprocesses work with parallel builds.
Properly set for_host for proc-macro tests.
Proc-macro tests are currently forced to run for the host target (by [this line of code](898ccde7ac/src/cargo/ops/cargo_compile.rs (L819))). However, the code that builds the dependency graph wasn't playing by the same rules, and was building the proc-macro test as-if it was "not for_host". This would cause the proc-macro test to pull in the wrong set of dependencies/features with the new feature resolver.
Forcing proc-macro tests to run on host isn't 100% required, since most targets have the proc_macro crate available. However, I feel like it simplifies things to build for-host. I was thinking we could relax that requirement, but I'm not really sure. See also #4336 where there's an bug if you do specify `--target`.
Tested with the wasmtime repo running `cargo test -Zfeatures=all -p wiggle-macro` with `doctest = false` commented out of `crates/wiggle/macro/Cargo.toml`.
Fixes#8563.
Sub-makes are currently not supported as the jobserver crate only
sets CARGO_MAKEFLAGS which GNU Make doesn't understand.
This might be reasonable as cargo overriding existing MAKEFLAGS
variables would be weird, but also makes the statement in the
reference false.
It's helpful for build script authors who want to invoke make
to know how to get make subprocesses work with parallel builds.
Add Zsh completion for target triples
Target triples are used for specifying targets for e.g. `cargo build --target thumbv7em-none-eabihf` where `thumbv7em-none-eabihf` is the target triplet.
For more information on target triples, see <https://doc.rust-lang.org/cargo/appendix/glossary.html#target>.
Target triples are used for specifying targets for e.g. `cargo build
--target thumbv7em-none-eabihf` where `thumbv7em-none-eabihf` is the
target triplet.
For more information on target triples, see
<https://doc.rust-lang.org/cargo/appendix/glossary.html#target>.
Reinitialize index on "Object not found" error.
Fixes#4007
Users have occasionally been reporting "Object not found" errors when updating the index. This PR changes cargo to detect this error, and delete the index and attempt one more time to update it. Our best theory is that the git repo is getting corrupted or out-of-sync somehow.
**Other options**
We talked about having cargo generate a ZIP file of the corrupt repo and ask the user to upload it to the issue tracker, but I feel like that isn't going to be too useful (there will be an object missing in the repo, which is unlikely to tell us how to got lost).
We could also implement some tricks to make the fetch process more atomic (by renaming the git directory before starting the fetch), but I'm uncertain if the added complexity is justified.
Another option (which I personally like) is to use `net.git-fetch-with-cli` by default if `git` is found in `PATH`. It is faster and more reliable and handles authentication better, and I suspect the vast majority of developer and CI systems have `git` installed. This kinda sweeps the problems of libgit2 under the rug, and would mean a huge amount of code would no longer be exercised by most users, leaving the few without `git` to be more likely to suffer obscure bugs.
**Testing**
Note that I was unable to create a local test to reproduce this, but I was able to reproduce against GitHub. I took my index repo and removed the most recent pack file, and then ran `cargo fetch`. This resulted in the exact same error users are reporting. I believe I cannot repro locally because the network update code is significantly different from the `file://` update code (there's all sorts of negotiation that happens over the protocol). Unless anyone has ideas on how to repro this in an automated fashion, I'm out of ideas.
**Other corruption**
In testing, I noticed there are a few other ways the "Object not found" error can happen, but this does not address them. Both cases involved deleting pack files:
1. After deleting the oldest pack file in an index, running an update, the index fetch succeeds. But then, when the `RemoteRegistry` attempts to load the `config.json` file, it can't find it (it fails [here](05c611ae3c/src/cargo/sources/registry/remote.rs (L181))).
2. After deleting the newest pack file of a git dependency in the `db` directory, the fetch succeeds, but then the call to `reset` of the checkout fails (around [here](05c611ae3c/src/cargo/sources/git/utils.rs (L480))).
Fixing these I think will be require a bit of work, since retry loops will need to be added. I'm not too eager to do that since nobody has reported an error with either of these cases (the error stack is slightly different).
Normalize raw string indentation.
It has always slightly bugged me how strings were indented after rustfmt was run across the repo (#5176). This attempts to normalize the strings so that they open and close on the same column. This only touches the `tests` directory.
Add contributor guide.
This consolidates and extends the contributor information in a single place. This is an mdbook project, along with a CI job which will build and deploy it to GitHub Pages at <https://rust-lang.github.io/cargo/contrib/>.
You can view a rendered version here: <https://ehuss.github.io/cargo/contrib/>
I don't know if this will actually be helpful to anyone, but I figured it's worth a shot.
NOTE: The CI deploy is designed to preserve the existing gh-pages content. However, it will **delete the history** on that branch. I think that should be fine, there doesn't seem to be too much interesting stuff there. I do have a backup in my fork, though. Some extra scrutiny on the code might be wise. The reason it deletes the history is because deploying mdbook on every push would balloon the repository size.
Fix minor error in `cargo update` docs.
`cargo update` does not require `Cargo.lock` to exist.
Also updated `generate-lockfile` to maybe be a little clearer (to me).
Add plain message format for locate-project
Supersedes #8683, as recommended in https://github.com/rust-lang/cargo/pull/8683#issuecomment-692921559. This PR adds a flag `--message-format` to `cargo locate-project` with possible values `json` (default) and `plain`.
```console
$ cargo locate-project --message-format json
{"root":"/git/cargo/Cargo.toml"}
$ cargo locate-project --message-format plain
/git/cargo/Cargo.toml
```
Closes#8009.
Add test for whitespace behavior in env flags.
This is a regression test to ensure that RUSTFLAGS/RUSTDOCFLAGS are split on just the space (0x20) character, and not any other whitespace. Requested at https://github.com/rust-lang/rust/pull/75539/files#r470923329
Fix non-determinism with new feature resolver.
This fixes a problem where Cargo was getting confused when two units were identical, but linked to different dependencies. Cargo generally assumes `Unit` is unique, but the new feature resolver can introduce a situation where two identical `Unit`s need to link to different dependencies. In particular, when building without the `--target` flag, the difference between a host unit and a target unit is not captured in the `Unit` structure. A dependency shared between normal dependencies and build dependencies can need to link to a second shared dependency whose features may be different.
The solution here is to build the unit graph pretending that `--target` was specified. Then, after the graph has been built, a second pass replaces `CompileKind::Target(host)` with `CompileKind::Host`, and adds a hash of the dependencies to the `Unit` to ensure it stays unique when necessary. This is done to ensure that dependencies are shared if possible.
I did a little performance testing, and I couldn't measure an appreciable difference. I also ran the tests in a loop for a few hours without problems.
An alternate solution here is to assume `--target=host` if `--target` isn't specified, and then have some kind of backwards-compatible linking in the `target` directory to retain the old directory layout. However, this would result in building shared host/normal dependencies twice. For *most* projects, this isn't a problem. This already happens when `--target` is specified, or `--release` is used (due to #8500). I'm just being very cautious because in a few projects this can be a large increase in build times. Maybe some day in the future we can be more bold and force this division, but I'm a little hesitant to make that jump.
Fixes#8549
