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
Add --name suggestion for cargo new
Resolves#8613
Since `check_name` have already got a parameter to show name help, I reuse the logic and sync the behavior between `cargo init` and `cargo new`. The divergence seems to be intentionally made in #7959:
_...Only print the --name suggestion for `cargo init`._
Feel free to discuss.
Sweep unrelated message from unnecessary workspace infromation
Resolves#8619
Only pass workspace information when the source is from a local crate installation.
Allow running build-man.sh from any directory
Before:
```console
$ src/doc/build-man.sh
error: manifest path `../../crates/mdman/Cargo.toml` does not exist
```
After: works.
Fix nightly exported_priv_warning test.
Error messages have slightly changed due to https://github.com/rust-lang/rust/pull/73996 to not include the full path. I used a `[..]` match just in case anyone is still using a slightly older nightly, or if it changes again in the future.
