bors [Fri, 2 Oct 2020 14:53:21 +0000 (14:53 +0000)]
Auto merge of #8744 - roblabla:homepage-doc-cargo-metadata, r=alexcrichton
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`.
Auto merge of #8742 - ehuss:proc-macro-test-feature, r=alexcrichton
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](https://github.com/rust-lang/cargo/blob/898ccde7ac867ecdb62184714b379c4328409399/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`.
Auto merge of #8740 - nop:target-completion, r=ehuss
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>.
Auto merge of #8735 - ehuss:git-object-not-found, r=alexcrichton
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](https://github.com/rust-lang/cargo/blob/05c611ae3c4255b7a2bcf4fcfa65b20286a07839/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](https://github.com/rust-lang/cargo/blob/05c611ae3c4255b7a2bcf4fcfa65b20286a07839/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).
Auto merge of #8739 - ehuss:normalize-raw-strings, r=alexcrichton
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.
Auto merge of #8715 - ehuss:contrib, r=alexcrichton
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.
Auto merge of #8727 - ehuss:badges, r=alexcrichton
Remove some badges documentation.
Badges have been removed from crates.io, so this updates the documentation. I don't think Cargo should manage a schema for the different services, and since crates.io isn't using these, I think it is mostly a dead feature. I left the `maintenance` field, because that might still have some meaning in the future.
More details:
* Removal from crates.io: https://github.com/rust-lang/crates.io/issues/2436 https://github.com/rust-lang/crates.io/pull/2440
* Solicited feedback for this change: https://internals.rust-lang.org/t/cargo-badges/12982
* Potential future support of `maintenance` status: https://github.com/rust-lang/crates.io/issues/2437 https://github.com/rust-lang/crates.io/issues/2438 https://github.com/rust-lang/crates.io/pull/2439. It's not clear, if crates.io manages the status in the database, the motivation for putting it in `Cargo.toml` is probably pretty small.
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`.
Auto merge of #8706 - ehuss:flag-whitespace-test, r=alexcrichton
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
Auto merge of #8701 - ehuss:unique-unit-dep-hash, r=alexcrichton
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.
Auto merge of #8675 - weihanglo:fix/name-help, r=Eh2406
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`._
Auto merge of #8678 - ehuss:fix-priv-test, r=alexcrichton
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.
Auto merge of #8672 - dtolnay:cachedir, r=alexcrichton
End CACHEDIR.TAG with newline
Before:
```
/path/to$ cat target/CACHEDIR.TAG
Signature: 8a477f597d28d172789f06886806bc55
# This file is a cache directory tag created by cargo.
# For information about cache directory tags see https://bford.info/cachedir//path/to$ ▎
```
After:
```
/path/to$ cat target/CACHEDIR.TAG
Signature: 8a477f597d28d172789f06886806bc55
# This file is a cache directory tag created by cargo.
# For information about cache directory tags see https://bford.info/cachedir/
/path/to$ ▎
```
Auto merge of #8671 - pjmore:master, r=alexcrichton
Fixed the fossil repo initialization actually run commands
I noticed that when using fossil cargo new would not ignore the target directory and that the commands to do so weren't being executed. I wasn't sure if opening an issue was needed as the fix is extremely simple, if an issue is needed I can create one.
bors [Fri, 28 Aug 2020 15:39:13 +0000 (15:39 +0000)]
Auto merge of #8657 - ehuss:fix-doctest-lto, r=alexcrichton
Fix LTO with doctests.
This fixes an issue where `cargo test --release` would fail to run doctests if LTO is set in `profile.release` or `profile.bench`.
The issue is that dependencies were built with `-Clinker-plugin-lto`, but the final rustdoc invocation did not issue `-C lto`. This causes a link failure (or crash!) because the necessary object code was missing. This is because rustdoc historically did not support codegen flags, so Cargo has never passed them in. Rustdoc now supports codegen flags (via https://github.com/rust-lang/rust/pull/63827), so it should be safe to start passing them in. For now, I am only adding LTO, but more should be added in the future.
There are two bugs here. One is that LTO flags aren't passed to rustdoc. The other is that the "doctest" unit was using the wrong profile (it was using dev/release when it should be using test/bench).
There are two distinct scenarios here. One where just `release` has `lto` set. And one where both `release` and `bench` have `lto` set. This is relevant because LTO mostly cares about what the final artifact wants, and in the case where `bench` does not have `lto` set, then LTO will not be used for tests. This will hopefully be a little cleaner in the future when #6988 is stabilized, which causes the test/bench profiles to *inherit* from the dev/bench profiles, which means you won't need to manually synchronize the test/bench profiles with dev/release.
bors [Wed, 26 Aug 2020 18:59:57 +0000 (18:59 +0000)]
Auto merge of #8653 - ehuss:fix-cache-messages-rustdoc-test, r=alexcrichton
Fix cache_messages::rustdoc test broken on beta.
The most recent beta `rustc 1.47.0-beta.1` broke this test (https://github.com/rust-lang/rust/issues/75951). Just switch to a different lint to get the test working again.
Eugene [Tue, 25 Aug 2020 13:05:25 +0000 (16:05 +0300)]
Add spaces after -C and -Z flags for consistency
Most other options have a space after flag name.
This commit makes verbose output of rustc invocations a little bit cleaner.
bors [Sun, 23 Aug 2020 13:07:55 +0000 (13:07 +0000)]
Auto merge of #8641 - weihanglo:fix/remove-alloc, r=Eh2406
fix: remove unnecessary allocations
Remove unnecessary `str::to_string` and `str::replace` allocations by using iterators. This PR is almost identical to #8622 except it does not skip the generated header.
Sorry that I did not profile the changes by myself. Seems that valgrind does not support macOS 10.15.6, I have not idea how to profile cargo subcommand. It would be great for an instruction to run a memory profiling for Rust program on macOS.
bors [Wed, 19 Aug 2020 20:22:52 +0000 (20:22 +0000)]
Auto merge of #8609 - ehuss:resolver-semver, r=Eh2406
Add chapters on dependency resolution and SemVer compatibility.
This adds two documentation chapters, one on the resolver and one on SemVer compatibility. These are intended to help guide users on how to version their package and how to use dependencies.
I did not document `[patch]` resolution. Perhaps someday in the future the the "Overriding dependencies" chapter can be expanded to include more details on how patch works, and how to properly use it. I have a bunch of notes on this, but I want to defer it till later.
The SemVer compatibility guidelines were guided by [RFC 1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md), but are edited and expanded based on my own personal observations. I tried to highlight when some rules do not appear to have consensus on behavior. I would be happy for any additions or modifications to the rule list. I have a list of additional things to add, but I wanted to get the ball rolling, and it might take a while finish them.
Each compatibility entry has an example, and there is a small script which tests all the examples to ensure they work like they are supposed to. This script checks against the compiler output, which can be fragile over time. If that becomes too troublesome, we can probably find some more relaxed checks. I think checking the error is important because I've run into cases in the past where using basic "compile_fail" annotations were misleading because the examples were failing for the wrong reason.
bors [Wed, 19 Aug 2020 19:30:21 +0000 (19:30 +0000)]
Auto merge of #8611 - hbina:rename_into_url, r=ehuss
Renames SourceId::into_url -> SourceId::as_url
While studying the source code, I am surprised to see that `into_url`
does not actually consume its caller when a function with such name
usually does. Additionally, there is a trait in `cargo::util::IntoUrl`
with the same and does exactly what you expect, consumes itself and yields
a `CargoResult<Url>`.
bors [Tue, 18 Aug 2020 16:52:45 +0000 (16:52 +0000)]
Auto merge of #8629 - EmbarkStudios:master, r=ehuss
Fix bug with PathAndArg config values
This fixes an issue I noticed when trying to specify a target runner via the [`CARGO_TARGET_{triplet}_RUNNER`](https://doc.rust-lang.org/cargo/reference/config.html#targettriplerunner) environment variable, expecting it to override the value in our `.cargo/config.toml` file, which was giving quite strange errors until I figured out that cargo was actually merging the config file's values with the environment's values.
This change adds a small hack to use and `UnmergedStringList` from `PathAndArgs` instead of just plain `StringList`, which uses the type in the deserializer to determine if `Config::get_list_or_string` should merge the values from the config file(s) with the environment as it was doing before, or else only use the environment to the exclusion of the config file(s) if the key was set in the environment.
I also added a test for this to confirm both the bug and the fix.
projects / cargo.git / log