Auto merge of #4808 - alexcrichton:fix-errors, r=alexcrichton

Relax a few error messages from libgit2

They were tweaked a bit recently so let's enusre they're not too strict.

Relax a few error messages from libgit2

They were tweaked a bit recently so let's enusre they're not too strict.

Auto merge of #4801 - bennyyip:master, r=alexcrichton

Add .ignore to pijul

Add .ignore to pijul

Auto merge of #4784 - SimonSapin:default-members, r=matklad

Fix `default-members` docs: it also applies to non-virtual workspaces.

Fix `default-members` docs: it also applies to non-virtual workspaces.

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.

Don't incorrectly compute cur from binary heap

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)
```

Auto merge of #4780 - alexcrichton:fix-reset, r=matklad

Reconfigure curl handles after reset

This'll ensure that all our proxy/speed data/etc will be preserved in the
libcurl configuration

Closes #4779

Reconfigure curl handles after reset

This'll ensure that all our proxy/speed data/etc will be preserved in the
libcurl configuration

Closes #4779

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.

Fixes #4771.

Auto merge of #4740 - nox:rustdocflags, r=alexcrichton

Pass RUSTDOCFLAGS to rustdoc spawned through cargo test (fixes #4738)

Pass RUSTDOCFLAGS to rustdoc spawned through cargo test (fixes #4738)

Auto merge of #4767 - nox:cargo-home-escape, r=matklad

Don't recurse out of CARGO_HOME when looking for workspace root

This fixes #4765.

Auto merge of #4766 - alexcrichton:bump, r=alexcrichton

Bump to 0.25.0

Don't recurse out of CARGO_HOME when looking for workspace root

This fixes #4765.

Bump to 0.25.0

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

cc @nox

Document that cargo sets `CARGO` for build scripts

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`).

Remove macro_use that's no longer needed

Update dylib check test to explicitly express that it doesn't cause rebuilds

Auto merge of #4743 - SimonSapin:default-members, r=matklad

Add a workspace.default-members config that overrides implied --all

Fixes #4507.

Document `workspace.default-members`

Update virtual workspace docs for implied --all

https://github.com/rust-lang/cargo/pull/4335

Expand documentation for Workspace::default_members field

Make default-members apply to non-virtual workspaces too

Add a workspace.default-members config that overrides implied --all

When no package is selected with `-p`, the default behavior
for virtual workspaces is to select every member
as if `--all` were used.

Allow metadata hash to be computed when checking dylibs

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.

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.

Pin nightlies temporarily

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.

Add missing spaces around = sign

Clarify that [patch] can also use sources that are not crates.io

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.

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.

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.

Auto merge of #4713 - alexcrichton:fix-bsd, r=matklad

Fix compilation on more platforms

Auto merge of #4711 - alexcrichton:fix-dep-info, r=matklad

Fix dep info showing up with a build script

Cargo would erroneously bail out early and accidentally forget to emit a
dep info file if any dependency used a build script, so this fixes that!

Auto merge of #4673 - pornel:bins, r=alexcrichton

List available binary names

When a project has multiple executables `cargo run` fails, but offers an incomplete solution (suggests `--bin`, but not its arguments.)

This PR adds a list of available binary names to the error message.

Fix dep info showing up with a build script

Cargo would erroneously bail out early and accidentally forget to emit a
dep info file if any dependency used a build script, so this fixes that!

Fix compilation on more platforms

Auto merge of #4710 - steveklabnik:fix-broken-links, r=Mark-Simulacrum

Fix broken links in cargo book

Needed to address failures in https://github.com/rust-lang/rust/pull/45692

Fix broken links in cargo book

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.

This fixes #4703.

Fix yank help.

Code review markups.

Auto merge of #4702 - mathstuf:update-lockfile-switch-colors, r=alexcrichton

cargo_generate_lockfile: flip Updating and Adding colors

Updating is green elsewhere and is more common as well.

---
Cc: @alexcrichton

cargo_generate_lockfile: flip Updating and Adding colors

Updating is green elsewhere and is more common as well.

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.

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.

Sort out bug with updating registry on a clean build.

Code review markups.

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.

**Downloading all Servo's dependencies**

[](https://asciinema.org/a/JX9yQZtyFo5ED0Pwg45barBco)

**Long running resolution**

[](https://asciinema.org/a/p7xAkSVeMlkyvgcI6Gx7DZjAV)

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.

Auto merge of #4695 - behnam:doc-book, r=alexcrichton

[doc/book] Change title to The Cargo Book

Also add "community’s" to description of crates.io, as Cargo now
supports multiple registries.

Auto merge of #4696 - paulkernfeld:master, r=matklad

Note that token can be read from stdin

Note that token can be read from stdin

[doc/book] Change title to The Cargo Book

Also add "community’s" to description of crates.io, as Cargo now
supports multiple registries.

Use the correct interface for creating an alternative registry source id.

Include registry in dependencies in the index.

Merge remote-tracking branch 'upstream/master' into alt-registry-publish-wip

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?

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.

Add verification that an crate has been published to the correct location.

Auto merge of #4691 - nbianca:patch-1, r=alexcrichton

Improved README.

Made some miscellaneous improvements.

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.

Improved README.

Alternative list display

List available binary names

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.

Sort out remaining file permissions.

Updated tests based on review comments.

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.

Context: https://github.com/rust-lang/cargo/issues/4563#issuecomment-340238773

r? @alexcrichton

Add feature gate on publish field changes.

Don't update lockfiles from previous Cargo versions if `--locked` is passed

Switch over to use --registry for publish list.

Merge branch 'registry-login' into alt-registry-publish-wip

Switching over to get-string for registry credentials.

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.

Explain why we are not using 'cache: cargo' with Travis

Auto merge of #4685 - ehuss:all-targets-no-lib, r=alexcrichton

Fix --all-targets in a crate without a lib.

Fixes #4615.

Fix --all-targets in a crate without a lib.

Fixes #4615.

Updating based on review comments.

Adding unstable-options flag to feature gate the use of --registry option.

Auto merge of #4561 - nossralf:uninstall-many, r=matklad

Support uninstallation of multiple packages

This is a WIP pull request with support for uninstalling multiple packages. It mirrors the logic used for `cargo install`.

Fixes #4560

Use specific methods to add requirements

Move logic for walking over dependent features around

Move shared logic into separated methods

Extract method for handling feature requirements

Extract method for recording a requested dependency

Extract function to record if a feature was seen before

Extract method for requiring crate features

Move resolution requirement state into a separate struct

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!

New error message with issue link

Improving the error message for when a patched dependency does not resolve to anything

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`).

Summary of the profiles used with this patch:

Command                         | Lib               | Bin foo     | Test t1 | Example e1 | Bench b1 |
-------                         | ---               | -------     | ------- | ---------- | -------- |
`check`                         | check             | check       | -       | -          | -        |
`check --profile test`          | check_test†       | check_test† | -       | -          | -        |
`check --lib`                   | check             | -           | -       | -          | -        |
`check --lib --profile test`    | check_test†       | -           | -       | -          | -        |
`check --bin foo`               | check             | check       | -       | -          | -        |
`check -–bin foo –profile test` | check_test†       | check_test† | -       | -          | -        |
`check --bins`                  | check             | check       | -       | -          | -        |
`check --test t1`               | check             | check       | check_test   | -          | -        |
`check --tests`                 | check, check_test†  | check, check_test† | check_test | check†, check_test†  | -    |
`check --all-targets`           | check, check_test†  | check, check_test†  | check_test   | check, check_test† | check_test    |

† = different behavior from today