bors [Tue, 5 Dec 2017 21:51:52 +0000 (21:51 +0000)]
Auto merge of #4782 - aidanhs:aphs-dont-incorrectly-compute-cur, r=alexcrichton
Don't incorrectly compute cur from binary heap
In the resolver, [`cur`](https://github.com/rust-lang/cargo/blob/0.23.0/src/cargo/core/resolver/mod.rs#L624) indicates how far through a 'deps frame' the resolver is, i.e. it indicates you're on the nth dep for a particular parent.
In 2015, [this refactoring commit](https://github.com/rust-lang/cargo/commit/502fa5b60a46a2349155562dcd7522ea56d338a7) made the value of `cur` be computed from the top of `remaining_deps`, a stack.
In 2016, [this commit](https://github.com/rust-lang/cargo/commit/4ec278feff81c8cbb92e37ea3dc6811f62351c7f) changed `remaining_deps` to be a binary heap to optimize cargo to choose the 'most constrained' dependencies first. Unfortunately, this means that you can no longer compute `cur`, because the relevant dep frame may not be at the 'top'. The result is that `cur` has been pretty arbitrary for about a year.
Is this a problem? `cur` is only used for debugging printouts so no...but it can underflow, panicking in debug mode! This PR stops incorrectly computing `cur`, storing it instead. It also enables overflow checking in Cargo in release mode for extra sanity checking - this (minor) bug would likely have been caught long ago and the opportunity to flush out other bugs in code that doesn't look arithmetic heavy seems like a good idea.
bors [Tue, 5 Dec 2017 16:32:16 +0000 (16:32 +0000)]
Auto merge of #4774 - lukaslueg:issue4771, r=alexcrichton
Break crate-descriptions at char-, not byte-boundary, avoiding a panic
Fixes #4771. The basic panicking-problem could be fixed by truncating at `char`- instead of `byte`-boundary. This PR takes the long route and uses the unicode-width to always truncate at grapheme-boundary, which should be visually correct in more cases. It adds two extra (extremely common) dependencies to Cargo, though. I have no strong opinions if this is worth it.
While truncating the descriptions, we now also take the length of the names-column into account, including margin, run a little shorter, and have them all of the same total true length.
Before
```
$ cargo search serde
serde = "1.0.23" # A generic serialization/deserialization framework
serde_json = "1.0.7" # A JSON serialization file format
serde_derive_internals = "0.17.0" # AST representation used by Serde derive macros. Unstable.
serde_yaml = "0.7.3" # YAML support for Serde
serde_derive = "1.0.23" # Macros 1.1 implementation of #[derive(Serialize, Deserialize)]
serde_test = "1.0.23" # Token De/Serializer for testing De/Serialize implementations
serde_bytes = "0.10.2" # Optimized handling of `&[u8]` and `Vec<u8>` for Serde
serde_millis = "0.1.1" # A serde wrapper that stores integer millisecond value for timestamps and durations (used similarly to serde_bytes)
serde_codegen_internals = "0.14.2" # AST representation used by Serde codegen. Unstable.
courier = "0.3.1" # Utility to make it easier to send and receive data when using the Rocket framework.
... and 275 crates more (use --limit N to see more)
```
After
```
$ cargo search serde
serde = "1.0.23" # A generic serialization/deserialization framework
serde_json = "1.0.7" # A JSON serialization file format
serde_derive_internals = "0.17.0" # AST representation used by Serde derive macros. Unstable.
serde_yaml = "0.7.3" # YAML support for Serde
serde_derive = "1.0.23" # Macros 1.1 implementation of #[derive(Serialize, Deserialize)]
serde_test = "1.0.23" # Token De/Serializer for testing De/Serialize implementations
serde_bytes = "0.10.2" # Optimized handling of `&[u8]` and `Vec<u8>` for Serde
serde_millis = "0.1.1" # A serde wrapper that stores integer millisecond value for …
serde_codegen_internals = "0.14.2" # AST representation used by Serde codegen. Unstable.
courier = "0.3.1" # Utility to make it easier to send and receive data when using …
... and 275 crates more (use --limit N to see more)
```
Lukas Lueg [Mon, 4 Dec 2017 15:43:53 +0000 (16:43 +0100)]
Break crate-descriptions at char-, not byte-boundary, avoiding a panic
Long running descriptions were truncated at byte-boundary, leading to a
panic during registry::search(); we now break at char-boundary.
Also take length of names-column into account to shorten descriptions.
bors [Wed, 29 Nov 2017 20:57:15 +0000 (20:57 +0000)]
Auto merge of #4764 - matklad:yo-dawg, r=alexcrichton
Document that cargo sets `CARGO` for build scripts
This documents and tests the current behavior.
However, I have two questions:
* Do we support recursively invoking Cargo from the build script?
* Do we support recursively invoking Cargo on the crate's own sources (ie, stuff inside `CARGO_HOME` which gets extracted from `.crate` files, and which in general is not byte-equal to the original sources).
Here's an interesting problem that Servo faced:
* Servo is a workspace.
* Servo's `CARGO_HOME` is inside sources.
* One of Servo's deps uses cbindgen from build.rs
* cbindgen [invokes](https://github.com/eqrion/cbindgen/blob/ef3bd8d307f01ad1171ab69cf911b712fbd73583/src/bindgen/cargo/cargo_metadata.rs#L106) Cargo to read Cargo.toml from a crate inside CARGO_HOME (which is inside worksapce).
This all failed to work as expected, because Cargo invoked by bindgen thought that workspace configuration was wrong.
The problem was fixed on the Servo side by using `exclude` key for workspace.
But do we actually guarantee that this is supposed to work? :) If we do, we might want to apply fix suggested by @nox and avoid looking for workspace root if we are inside `CARGO_HOME`.
Note that cbindgen will probably be broken for crates which are workspaces themselves, because we rewrite members to path dependencies, but, if you have an explicit `members` key, `cargo metadata` inside such workspace in `CARGO_HOME` will complain.
Original IRC discussion: https://botbot.me/mozilla/cargo/2017-11-29/?msg=94061970&page=3
bors [Wed, 29 Nov 2017 20:04:34 +0000 (20:04 +0000)]
Auto merge of #4763 - michaelfairley:master, r=alexcrichton
Allow metadata hash to be computed when checking dylibs
Currently, `cargo check` on a dylib crate will use the same fingerprint files as `build`, resulting in `build`s often having to re-do unnecessary work as previous `build`s fingerprints have been clobbered (specifically, the `profile` hash in the fingerprint will be wrong since `check` runs with a different profile than `build`).
bors [Wed, 29 Nov 2017 03:05:30 +0000 (03:05 +0000)]
Auto merge of #4736 - federicomenaquintero:clarify-patch-from-alternate-sources, r=alexcrichton
Clarify that [patch] can also use sources that are not crates.io
This includes an example of how to use the `[patch.'https://blahblah']` syntax. I couldn't figure out how to make this work until I saw a crate that actually did this.
bors [Wed, 29 Nov 2017 02:17:26 +0000 (02:17 +0000)]
Auto merge of #4762 - alexcrichton:fix-tests, r=alexcrichton
Fix the lockfile-compat test
The newest version of `tar` tweaks the checksum here slightly as the tarball is
slightly different, so this just updates the test to pull the checksum from the
publication rather than hardcoding it.
Alex Crichton [Wed, 29 Nov 2017 01:44:25 +0000 (17:44 -0800)]
Fix the lockfile-compat test
The newest version of `tar` tweaks the checksum here slightly as the tarball is
slightly different, so this just updates the test to pull the checksum from the
publication rather than hardcoding it.
bors [Sat, 18 Nov 2017 00:03:28 +0000 (00:03 +0000)]
Auto merge of #4568 - Metaswitch:alt-registry-publish, r=withoutboats
Add support for publish to optionally take the index that can be used
This form part of alternative-registries RFC-2141, it allows crates to optionally specify which registries the crate can be be published to.
@carols10cents, one thing that I am unsure about is if there is a plan for publish to still provide index, or for registry to be provided instead. I thought that your general view was that we should move away from the index file. If we do need to map allowed registries to the index then there will be a small amount of extra work required once #4506 is merged.
@withoutboats, happy for this to be merged into your branch if you want, the main reason I did not base it on your branch was due to tests not working on there yet.
bors [Sun, 12 Nov 2017 19:13:19 +0000 (19:13 +0000)]
Auto merge of #4714 - Mark-Simulacrum:frozen-freezes, r=alexcrichton
Do not update semantically equivalent lockfiles with --frozen/--locked.
A previous patch in #4684 attempted to fix this, but didn't work for the
case where the [root] crate wasn't the first crate in the sorted package
array.
cc @matklad -- fixes a problem noted in https://github.com/rust-lang/cargo/pull/4684#discussion_r147824900 which appears to have gone unfixed
r? @alexcrichton
Beta backport will be posted as soon as this is reviewed. Merges cleanly.
Mark Simulacrum [Sun, 12 Nov 2017 17:57:05 +0000 (10:57 -0700)]
Do not update semantically equivalent lockfiles with --frozen/--locked.
A previous patch in #4684 attempted to fix this, but didn't work for the
case where the [root] crate wasn't the first crate in the sorted package
array.
bors [Thu, 9 Nov 2017 07:39:03 +0000 (07:39 +0000)]
Auto merge of #4705 - Metaswitch:fix-yank-help, r=matklad
Stop yank -h from panicking on nightly
Increase the gap between the registry option and the description so that the help is parsed correctly. I have also checked the code for the other binaries to ensure that they don't suffer from the same issue.
bors [Tue, 7 Nov 2017 18:12:25 +0000 (18:12 +0000)]
Auto merge of #4701 - mathstuf:update-lockfile-color-reflects-change, r=alexcrichton
cargo_generate_lockfile: use color to also indicate the change
In English, `Updating` and `Removing` are the same length and scanning
the list for changes is hard. Use color to help indicate the kind of
change that is occurring.
Ben Boeckel [Tue, 7 Nov 2017 16:56:38 +0000 (11:56 -0500)]
cargo_generate_lockfile: use color to also indicate the change
In English, `Updating` and `Removing` are the same length and scanning
the list for changes is hard. Use color to help indicate the kind of
change that is occurring.
bors [Mon, 6 Nov 2017 18:35:46 +0000 (18:35 +0000)]
Auto merge of #4646 - alexcrichton:progress, r=matklad
Add a number of progress indicators to Cargo
This commit is an attempt to stem the tide of "cargo is stuck updating the
registry" issues by giving a better indication as to what's happening in
long-running steps. The primary addition here is a `Progress` helper module
which prints and manages a progress bar for long-running operations like git
fetches, git checkouts, HTTP downloads, etc.
The second addition here is to print out when we've been stuck in resolve for
some time. We never really have a progress indicator for crate graph resolution
nor do we know when we're done updating sources. Instead we make a naive
assumption that when you've spent 0.5s in the resolution loop itself (not
updating deps) you're probably done updating dependencies and on to acutal
resolution. This will print out `Resolving crate graph...` and help inform that
Cargo is indeed not stuck looking at the registry, but rather it's churning away
in resolution.
Alex Crichton [Mon, 16 Oct 2017 14:57:38 +0000 (07:57 -0700)]
Add a number of progress indicators to Cargo
This commit is an attempt to stem the tide of "cargo is stuck updating the
registry" issues by giving a better indication as to what's happening in
long-running steps. The primary addition here is a `Progress` helper module
which prints and manages a progress bar for long-running operations like git
fetches, git checkouts, HTTP downloads, etc.
The second addition here is to print out when we've been stuck in resolve for
some time. We never really have a progress indicator for crate graph resolution
nor do we know when we're done updating sources. Instead we make a naive
assumption that when you've spent 0.5s in the resolution loop itself (not
updating deps) you're probably done updating dependencies and on to acutal
resolution. This will print out `Resolving crate graph...` and help inform that
Cargo is indeed not stuck looking at the registry, but rather it's churning away
in resolution.
bors [Wed, 1 Nov 2017 15:24:12 +0000 (15:24 +0000)]
Auto merge of #4680 - Metaswitch:registry-login, r=alexcrichton
Support login tokens for multiple registries
This pull request builds on #4206 to support login using the the registry from alternate registries (RFC 2141). This includes the following changes:
- allow credentials to be stored based on the registry
- allow passing the registry to run cargo commands against using --registry
Note that this does not include a feature gate on the use of --registry as the publish code blocks publish if we use any features. @alexcrichton, are you happy with this approach, or is there a way that you would recommend this should be relaxed for testing purposes?
bors [Tue, 31 Oct 2017 22:13:57 +0000 (22:13 +0000)]
Auto merge of #4692 - nossralf:add-rustfmt-config, r=matklad
Add rustfmt.toml with formatting disabled
Currently, Cargo does not use rustfmt for its source code. By adding a rustfmt.toml that simply disables all formatting rules, editors which use rustfmt by default for all Rust code will do the right thing and leave the source code unchanged,.
This makes life a little bit easier for developers who no longer need to explicitly disable automatic rustfmt formatting when working on Cargo to avoid code unrelated to a change being reformatted.
Fredrik Larsson [Tue, 31 Oct 2017 21:31:02 +0000 (22:31 +0100)]
Add rustfmt.toml with formatting disabled
Currently, Cargo does not use rustfmt for its source code. By adding a
rustfmt.toml that simply disables all formatting rules, editors which
use rustfmt by default for all Rust code will do the right thing and
leave the source code unchanged.
bors [Tue, 31 Oct 2017 16:49:55 +0000 (16:49 +0000)]
Auto merge of #4683 - djc:requirements, r=alexcrichton
Introduce Requirements struct to clarify code
`cargo::core::resolver::build_requirements()` previously, in this order:
* Defined local variables to track state
* Called a function to mutate the local variables
* Defined the aforementioned function
* Returned two out of three local variables as a tuple
This PR changes the code so that this is a recast as a struct (appropriately called `Requirements`), which is mutated in a more fine-grained way by its methods and acts as the return type for `build_requirements()`. To me, this seems a lot easier to understand.
This work was done in the context of #1286, but I figured it was easier to start landing some of the refactoring to avoid bitrot and get early (well, earlier) feedback.
bors [Tue, 31 Oct 2017 14:14:46 +0000 (14:14 +0000)]
Auto merge of #4684 - matklad:lazy-update, r=alexcrichton
Don't update lockfiles from previous Cargo versions if `--locked` is passed
Recently, we've stopped outputting `[root]` section to Cargo.lock files. The problem with this is that somebody might want to have a Cargo.lock file with a `[root]` section for compatibility with older Cargos, but at the same time use newer Cargo to build the crate. In this case, newer Cargo would remove `[root]` from the lockfile. Such updating of the lockfiles to the latest versions is a reasonable behavior, but it might be useful to be able to override it with `--locked` flag.
bors [Tue, 31 Oct 2017 00:48:46 +0000 (00:48 +0000)]
Auto merge of #4676 - mgeisler:ci-caching, r=alexcrichton
Explain why caching is only done on $HOME/.cargo/bin/ in Travis
After having experimented with the Travis and AppVeyor caches, I concluded that they don't really help here: they're large and take a very long time to both download when the build starts and upload after it is finished.
bors [Mon, 30 Oct 2017 18:09:49 +0000 (18:09 +0000)]
Auto merge of #4607 - sunjay:patcherror, r=alexcrichton
Improving the error message for when a patched dependency does not resolve to anything
Hi,
I just spent a long time debugging what this error message means and so I thought I would try to help improve it. Could someone who knows the codebase well look at this and see if this error message even makes sense here. I know this is the information I would have needed, but the error may occur in other cases where this message doesn't make sense. I'm open to any suggestions that would help make it more clear and maybe point people to where they should look for more information.
The specific problem that I ran into occurred when I was trying to upgrade the `rustfmt` submodule in the rust codebase. The `rustfmt-nightly` dependency changed version numbers and this conflicted with what was in the `Cargo.lock` file. After some detective work I was able to find the [documentation on `[patch]`](http://doc.crates.io/manifest.html#the-patch-section) which I had never read before and the following relevant paragraphs from [some other documentation](http://doc.crates.io/specifying-dependencies.html#testing-a-bugfix):
> Next up we need to ensure that our lock file is updated to use this new version of uuid so our project uses the locally checked out copy instead of one from crates.io. The way [patch] works is that it'll load the dependency at ../path/to/uuid and then whenever crates.io is queried for versions of uuid it'll also return the local version.
>
> This means that the version number of the local checkout is significant and will affect whether the patch is used. Our manifest declared uuid = "1.0" which means we'll only resolve to >= 1.0.0, < 2.0.0, and Cargo's greedy resolution algorithm also means that we'll resolve to the maximum version within that range. Typically this doesn't matter as the version of the git repository will already be greater or match the maximum version published on crates.io, but it's important to keep this in mind!
If it was not for the person who wrote those docs, I would not have known what to do here!
bors [Mon, 30 Oct 2017 16:50:15 +0000 (16:50 +0000)]
Auto merge of #4592 - ehuss:check_test, r=alexcrichton
Add unit test checking to `cargo check`
This is an extension of PR #4039, fixing #3431, #4003, #4059, #4330. The fixes for #4059 can potentially be separated into a separate PR, though there may be some overlap.
The general gist of the changes:
- Add `--profile test` flag to `cargo check` that will enable checking of unit tests.
- `--tests` will implicitly enable checking of unit tests within the lib (checks the same targets as `cargo test`). This affects the `check`, `test`, and `build` commands.
- `--benches` behaves similarly by using the same targets as `cargo bench`.
- Fix erroneously linking tests when run with `--test`.
There is one thing I did not do because I wanted more feedback on what others think the expected behavior should be. What should the behavior of `--all-targets` be? This patch does not (yet) make any changes to its behavior. My initial thinking is that it should *add* a target of `--lib --bins --profile test`, but that essentially means the lib and bin targets will be checked twice (and thus any errors/warnings outside of `#[cfg(test)]` will appear twice, which may be confusing, and generally take twice as long to run). I can add that, but I think it would require adding a new `All` variant to `CompileFilter` so that the code in `generate_targets` can detect this scenario. I wanted feedback before making a more extensive change like that. The downside of not adding it is that `--all-targets` will ignore unit tests (if you don't specify `--profile test`).