Improve I/O error message for fingerprint of build script
It is a bit rough but I don't think there is a network I/O error
in `pkg_fingerprint`. Checking only `io::Error` type should be fine.
Resolves#9881
Explicitly mark aliases in `cargo list`.
This I think makes it a little clearer that these are aliases, and matches the form used for built-in aliases.
Don't emit "executable" JSON field for non-executables.
The "executable" field of JSON artifact messages was accidentally filled (with the path to `index.html`) when documenting a binary target. This fixes it so that it is null.
Closes#10149
Fix some profile documentation.
The `test` and `bench` sections had wrong information about which profile is used. This also has some changes to try to format and clarify selection a little.
Document lib before bin.
This changes it so that documenting a library is required to finish before documenting a binary. The issue is that the binary may have intra-doc links to the library. If they are documented concurrently, then the links will sometimes fail (since it is a race). Or, if doing `cargo doc --bins`, then the library docs wouldn't exist at all.
Note that in the tests this introduces some more name collisions if you just run `cargo doc --bins` and there is a colliding library/binary name. There is some risk that someone might be trying to run the commands separately to get around the collision error, but I think it is unlikely.
Sync cargo-the-cli version with rustc.
People occasionally get confused when cargo's version does not match the version of rustc. This happens in a variety of scenarios:
* Point releases.
* Beta releases (cargo is missing the .1 .2, etc.)
* Nightly releases when cargo's version has not yet been bumped.
This changes it so that cargo-the-cli will always report the same version as rustc (assuming they were built with rustbuild). The git information remains the same (reports cargo's last commit sha).
Closes#10122
This field is no longer being used, as pre-release versions have
not been used in cargo for quite some time, and I don't anticipate
them ever returning.
Support abbreviating `--release` as `-r`
Of the options people regularly pass to cargo, `--release` seems by far
the most common. Yet even on the command line, we expect people to type
out `--release`.
Add a short version `-r`, and add some tests in the testsuite that
confirm it works.
doc: nudge towards simple version requirements
Cargo is very ingeniously designed such that the simplest thing you can do when sepcifying a dependency, `time = "1.2.3"`, is also the best thing you can do. However, new Rust folks often overthink this, and use more verbose syntaxes, which at best is unnecessary, and and at worst creates pains downstream. For example, https://github.com/elastic/elasticsearch-rs/blob/master/elasticsearch/Cargo.toml contains a mistrue of default, `~` and `^` requirements, which lets the reader wondering what's going on.
Let's try to help the situation by focusing on default requirements in the docs
Add note about RUSTFLAGS removal from build scripts.
The RUSTFLAGS environment variable was removed from build scripts in #9601, but the release notes did not make a note of this change. This adds a highlight to this potentially breaking change.
