Always respect `CARGO_TARGET_DIR` during `cargo install`

This aligns the behavior of crates.io and `--git` sources with that of `--path`
regarding the `CARGO_TARGET_DIR` and `CARGO_BUILD_TARGET_DIR` environment
variables.  If neither environment variable is set, then a temporary directory
is still used when installing from crates.io or `--git`.

As discussed in #4725, this can be used to enable caching of artifacts between
continuous integration builds.

Auto merge of #4837 - alexcrichton:failed-submodule-checkout, r=matklad

Fix updating submodules past failures

If a submodule-of-a-submodule failed to update then Cargo the next time
around wouldn't automatically retry updating the next submodule. This commit
fixes that by ensuring that if a parent git repository looks updated we still
recurse into its own submodules to ensure they're all updated.

cc #4071

Fix updating submodules past failures

If a submodule-of-a-submodule failed to update then Cargo the next time
around wouldn't automatically retry updating the next submodule. This commit
fixes that by ensuring that if a parent git repository looks updated we still
recurse into its own submodules to ensure they're all updated.

cc #4071

Auto merge of #4838 - Manishearth:die-qquote, r=alexcrichton

Remove usage of quasi-quoting in tests

Only clippy and cargo use the old quasi quoting stuff, and we should be
removing it.

r? @alexcrichton

Remove usage of quasi-quoting in tests

Only clippy and cargo use the old quasi quoting stuff, and we should be
removing it.

Auto merge of #4791 - nox:dupe-flags, r=alexcrichton

Don't accumulate feature and rustdoc flags twice (fixes #4790)

Auto merge of #4795 - alexcrichton:failure, r=withoutboats

Start migration to the `failure` crate

This commit is the initial steps to migrate Cargo's error handling from the
`error-chain` crate to the `failure` crate. This is intended to be a low-cost
(in terms of diff) transition where possible so it's note "purely idiomatic
`failure` crate" just yet.

The `error-chain` dependency is dropped in this commit and Cargo now canonically
uses the `Error` type from the `failure` crate. The main last remnant of
`error-chain` is a custom local extension trait to use `chain_err` instead of
`with_context`. I'll try to follow up with a commit that renames this later but
I wanted to make sure everything worked first! (and `chain_err` is used
practically everywhere).

Some minor tweaks happened in the tests as I touched up a few error messages
here and there but overall the UI of Cargo should be exactly the same before and
after this commit.

Auto merge of #4836 - sfackler:dl-template, r=withoutboats

Template a registry's dl field

Previously, crate files were always downloaded from
`/{crate}/{version}/download`. However, if the backing crate store for a
custom registry is a raw file server rather than an API endpoint that
requires every file to be named `download` which is a bit weird. Now a
registry's dl URL can be templated with `{crate}` and `{version}` to
have more control over the resulting path.

For backwards compatibility, we append the default template suffix onto
the dl URL if neither of the template parameters are present for
backwards compatibility.

r? @alexcrichton

cc @withoutboats

Start migration to the `failure` crate

This commit is the initial steps to migrate Cargo's error handling from the
`error-chain` crate to the `failure` crate. This is intended to be a low-cost
(in terms of diff) transition where possible so it's note "purely idiomatic
`failure` crate" just yet.

The `error-chain` dependency is dropped in this commit and Cargo now canonically
uses the `Error` type from the `failure` crate. The main last remnant of
`error-chain` is a custom local extension trait to use `chain_err` instead of
`with_context`. I'll try to follow up with a commit that renames this later but
I wanted to make sure everything worked first! (and `chain_err` is used
practically everywhere).

Some minor tweaks happened in the tests as I touched up a few error messages
here and there but overall the UI of Cargo should be exactly the same before and
after this commit.

Avoid an intermediate allocation

Fix test for Windows

Auto merge of #4832 - andreastt:dumb_terminal_progress, r=alexcrichton

util/progress: no progress reporting in dumb terminals

cargo should not assume that all terminals have direct access to
the terminal.  Dumb terminals are those that can interpret only a
limited number of control codes (CR, LF, &c.) and the escape codes
used by the progress bar breaks output in these by asserting control
over the cursor position to draw a bar.

A dumb terminal is identified by the TERM output variable being set to
"dumb".  This adds a direct check for this in src/cargo/util/progress.rs
because TERM=dumb does not imply the same as the -q flag.

Template a registry's dl field

Previously, crate files were always downloaded from
`/{crate}/{version}/download`. However, if the backing crate store for a
custom registry is a raw file server rather than an API endpoint that
requires every file to be named `download` which is a bit weird. Now a
registry's dl URL can be templated with `{crate}` and `{version}` to
have more control over the resulting path.

For backwards compatibility, we append the default template suffix onto
the dl URL if neither of the template parameters are present for
backwards compatibility.

Auto merge of #4818 - alexcrichton:rename-link-paths, r=matklad

Fix renaming a project using build scripts

This commit fixes an issue in Cargo where if a project's folder was
renamed but it also contained a build script the project could break.
Cargo would continue to use the previous `rustc-link-search` arguments
to configure env vars like `LD_LIBRARY_PATH` but the literal values from
the previous compilation would be stale as the directories would no
longer be there.

To fix this when parsing the build script output we now retain a log of
the previous output directory of a build script invocation as well as
the current output, tweaking paths as appropriate if they were contained
in the output folder.

Closes #4053

Fix renaming a project using build scripts

This commit fixes an issue in Cargo where if a project's folder was
renamed but it also contained a build script the project could break.
Cargo would continue to use the previous `rustc-link-search` arguments
to configure env vars like `LD_LIBRARY_PATH` but the literal values from
the previous compilation would be stale as the directories would no
longer be there.

To fix this when parsing the build script output we now retain a log of
the previous output directory of a build script invocation as well as
the current output, tweaking paths as appropriate if they were contained
in the output folder.

Closes #4053

util/progress: no progress reporting in dumb terminals

cargo should not assume that all terminals have direct access to
the terminal.  Dumb terminals are those that can interpret only a
limited number of control codes (CR, LF, &c.) and the escape codes
used by the progress bar breaks output in these by asserting control
over the cursor position to draw a bar.

A dumb terminal is identified by the TERM output variable being set to
"dumb".  This adds a direct check for this in src/cargo/util/progress.rs
because TERM=dumb does not imply the same as the -q flag.

Auto merge of #4828 - SimonSapin:virtual-err, r=alexcrichton

Don’t swallow virtual manifest parsing errors

Before this change, `cargo::util::toml::do_read_manifest` ended like this:

```rust
    return match TomlManifest::to_real_manifest(/* … */) {
        Ok(/* … */) => /* … */,
        Err(e) => match TomlManifest::to_virtual_manifest(/* … */) {
            Ok(/* … */) => /* … */,
            Err(..) => Err(e),
        }
    };
```

Errors returned by `to_virtual_manifest` were always ignored. As a result, when something was wrong in a virtual manifest, Cargo would unhelpfully exit with no more output than:

```
error: failed to parse manifest at `/tmp/a/Cargo.toml`

Caused by:
  no `package` section found.
```

http://doc.crates.io/manifest.html#virtual-manifest defines a virtual manifest as “the `package` table is not present”, so let’s first determine if a manifest is virtual based on that criteria, and then only call one of the two methods.

Although it is not mentioned in the documentation, `[project]` seems to be in the code an alias for `[package]`. So let’s preserve that here too.

Don’t swallow virtual manifest parsing errors

Before this change, `cargo::util::toml::do_read_manifest` ended like this:

```rust
    return match TomlManifest::to_real_manifest(/* … */) {
        Ok(/* … */) => /* … */,
        Err(e) => match TomlManifest::to_virtual_manifest(/* … */) {
            Ok(/* … */) => /* … */,
            Err(..) => Err(e),
        }
    };
```

Errors returned by `to_virtual_manifest` were always ignored.
As a result, when something was wrong in a virtual manifest,
Cargo would unhelpfully exit with no more output than:

```
error: failed to parse manifest at `/tmp/a/Cargo.toml`

Caused by:
  no `package` section found.
```

http://doc.crates.io/manifest.html#virtual-manifest defines
a virtual manifest as “the `package` table is not present”,
so let’s first determine if a manifest is virtual based
on that criteria, and then only call one of the two methods.

Although it is not mentioned in the documentation,
`[project]` seems to be in the code an alias for `[package]`.
So let’s preserve that here too.

Auto merge of #4826 - alexcrichton:silence-progress, r=matklad

Don't print a progress bar in quiet mode

Closes #4825

Don't print a progress bar in quiet mode

Closes #4825

Auto merge of #4823 - johnthagen:patch-1, r=alexcrichton

Add note about running clean before using -vv for build script development

This solves an issue that came up in the beginners chat that took about fifteen minutes to finally understand what was going on.

This should help users who are actively developing `build.rs` consistently get debugging information printed to the terminal.

Auto merge of #4822 - integer32llc:more-custom-http-transport, r=alexcrichton

Use the custom HTTP transport when any HTTP settings are present

We no longer need to workaround AppVeyor's SSL revocation

Add note about running clean before using -vv

This solves an issue that came up in the beginners chat that took about fifteen minutes to finally understand what was going on.

This should help users who are actively developing `build.rs` consistently get debugging information printed to the terminal.

Auto merge of #4821 - aidanhs:aphs-allow-overflow, r=alexcrichton

Remove overflow checks to eliminate rust build warnings

Although the checks are desirable, they cause warnings in the rust build (due to workspaces) which could cause needless concern. The checks aren't too important, so just disable them.

r? @alexcrichton (as discussed)

Remove overflow checks to eliminate rust build warnings

Although the checks are desirable, they cause warnings in the rust build
(due to workspaces) which could cause needless concern. The checks
aren't too important, so just disable them.

Use the custom HTTP transport when any HTTP settings are present

Auto merge of #4816 - alexcrichton:fix-workspace-is-home, r=matklad

Defer bailing out workspace root probing

This commit alters the logic to bail out on probing for `CARGO_HOME` to
do it a little later rather than early on in the loop iteration, notably
allowing members to reside in `CARGO_HOME` itself.

Closes #4815

Defer bailing out workspace root probing

This commit alters the logic to bail out on probing for `CARGO_HOME` to
do it a little later rather than early on in the loop iteration, notably
allowing members to reside in `CARGO_HOME` itself.

Closes #4815

Auto merge of #4812 - tomprince:patch-1, r=matklad

Fix comment typo.

Auto merge of #4788 - alexcrichton:rename-works, r=matklad

Avoid rebuilding a project when cwd changes

This commit is targeted at solving a use case which typically comes up during CI
builds -- the `target` directory is cached between builds but the cwd of the
build changes over time. For example the following scenario can happen:

1. A project is compiled at `/projects/a`.
2. The `target` directory is cached.
3. A new build is started in `/projects/b`.
4. The previous `target` directory is restored to `/projects/b`.
5. The build start, and Cargo rebuilds everything.

The last piece of behavior is indeed unfortunate! Cargo's internal hashing
currently isn't that resilient to changing cwd and this PR aims to help improve
the situation!

The first point of too-much-hashing came up with `Target::src_path`. Each
`Target` was hashed and stored for all compilations, and the `src_path` field
was an absolute path on the filesystem to the file that needed to be compiled.
This path then changed over time when cwd changed, but otherwise everything else
remained the same!

This commit updates the handling of the `src_path` field to simply ignore it
when hashing. Instead the path we actually pass to rustc is later calculated and
then passed to the fingerprint calculation.

The next problem this fixes is that the dep info files were augmented after
creation to have the cwd of the compiler at the time to find the files at a
later date. This, unfortunately, would cause issues if the cwd itself changed.
Instead the cwd is now left out of dep-info files (they're no longer augmented)
and instead the cwd is recalculated when parsing the dep info later.

The final problem that this commit fixes is actually an existing issue in Cargo
today. Right now you can actually execute `cargo build` from anywhere in a
project and Cargo will execute the build. Unfortunately though the argument to
rustc was actually different depending on what directory you were in (the
compiler was invoked with a path relative to cwd). This path ends up being used
for metadata like debuginfo which means that different directories would cause
different artifacts to be created, but Cargo wouldn't rerun the compiler!

To fix this issue the matter of cwd is now entirely excluded from compilation
command lines. Instead rustc is unconditionally invoked with a relative path
*if* the path is underneath the workspace root, and otherwise it's invoked as an
absolute path (in which case the cwd doesn't matter).

Once all these fixes were added up it means that now we can have projects where
if you move the entire directory Cargo won't rebuild the original source!

Note that this may be a bit of a breaking change, however. This means that the
paths in error messages for cargo will no longer be unconditionally relative to
the current working directory, but rather relative to the root of the workspace
itself. Unfortunately this is moreso of a feature right now rather than a bug,
so it may be one that we just have to stomach.

Closes https://github.com/rust-lang/cargo/issues/3273

Fix comment typo.

Change Cargo's own dep-file format

This commit alters the format of the dependency info that Cargo keeps track of
for each crate. In order to be more resilient against directory renames and such
Cargo will now postprocess the compiler's dep-info output and serialize into its
own format. This format is intended to primarily list relative paths *to the
root of the relevant package* rather than absolute or relative to some other
location. If paths aren't actually relative to the package root they're still
stored as absolute, but there's not much we can do about that!

Auto merge of #4806 - alexcrichton:fix-infinite-loop, r=matklad

Fix an infinite loop in error reporting

The `path_to_root` function unfortunately didn't account for cycles in the
dependency graph introduced through dev-dependencies, so if a cycle was present
then the function would infinitely loop pushing items onto a vector.

This commit fixes the infinite loop and also touches up the reporting to be a
little more consistent with the rest of Cargo

Auto merge of #4797 - lukaslueg:issue3169, r=alexcrichton

Bail out when trying to link to a library that is not linkable.

There are more subtleties here than expected, as we can have situations where it is actually Ok to have no linkable targets: Build scripts are a common case, yet benchmark tests started to also fail. I have to say I'm not convinced if the situation "not one target is linkable, yet at least one target is a library (and therefor at least something should be linked)" is actually correct. All tests pass, however, including the one that checks for #3169

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.

Warn when trying to link to a library that is not linkable.

If a dependency is a library that provides no linkable targets, we warn
about the impending error in rustc about an unresolvable `extern crate`.

Fixes #3169.

Fix an infinite loop in error reporting

The `path_to_root` function unfortunately didn't account for cycles in the
dependency graph introduced through dev-dependencies, so if a cycle was present
then the function would infinitely loop pushing items onto a vector.

This commit fixes the infinite loop and also touches up the reporting to be a
little more consistent with the rest of Cargo

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

Add .ignore to pijul

Add .ignore to pijul

Don't accumulate feature and rustdoc flags twice (fixes #4790)

Avoid rebuilding a project when cwd changes

This commit is targeted at solving a use case which typically comes up during CI
builds -- the `target` directory is cached between builds but the cwd of the
build changes over time. For example the following scenario can happen:

1. A project is compiled at `/projects/a`.
2. The `target` directory is cached.
3. A new build is started in `/projects/b`.
4. The previous `target` directory is restored to `/projects/b`.
5. The build start, and Cargo rebuilds everything.

The last piece of behavior is indeed unfortunate! Cargo's internal hashing
currently isn't that resilient to changing cwd and this PR aims to help improve
the situation!

The first point of too-much-hashing came up with `Target::src_path`. Each
`Target` was hashed and stored for all compilations, and the `src_path` field
was an absolute path on the filesystem to the file that needed to be compiled.
This path then changed over time when cwd changed, but otherwise everything else
remained the same!

This commit updates the handling of the `src_path` field to simply ignore it
when hashing. Instead the path we actually pass to rustc is later calculated and
then passed to the fingerprint calculation.

The next problem this fixes is that the dep info files were augmented after
creation to have the cwd of the compiler at the time to find the files at a
later date. This, unfortunately, would cause issues if the cwd itself changed.
Instead the cwd is now left out of dep-info files (they're no longer augmented)
and instead the cwd is recalculated when parsing the dep info later.

The final problem that this commit fixes is actually an existing issue in Cargo
today. Right now you can actually execute `cargo build` from anywhere in a
project and Cargo will execute the build. Unfortunately though the argument to
rustc was actually different depending on what directory you were in (the
compiler was invoked with a path relative to cwd). This path ends up being used
for metadata like debuginfo which means that different directories would cause
different artifacts to be created, but Cargo wouldn't rerun the compiler!

To fix this issue the matter of cwd is now entirely excluded from compilation
command lines. Instead rustc is unconditionally invoked with a relative path
*if* the path is underneath the workspace root, and otherwise it's invoked as an
absolute path (in which case the cwd doesn't matter).

Once all these fixes were added up it means that now we can have projects where
if you move the entire directory Cargo won't rebuild the original source!

Note that this may be a bit of a breaking change, however. This means that the
paths in error messages for cargo will no longer be unconditionally relative to
the current working directory, but rather relative to the root of the workspace
itself. Unfortunately this is moreso of a feature right now rather than a bug,
so it may be one that we just have to stomach.

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.