Depend on rustc 1.24 or later

Prepare upload to unstable.

Prepare release

Disable tests on powerpc and powerpcspe

Prepare new release for experimental

Update copyright for 0.25.0

Drop unused lintian override for README as patch.

Request to not consider README under patches as a patch file has been
implemented in lintian upstream.

Fix typo in 2006 patch description.

Drop patch 0001 as its merged upstream.

Update upstream source from tag 'upstream/0.25.0'

Update to upstream version '0.25.0'
with Debian dir 44c2a43b3d0c56627bb5fb049db7430d3382d218

New upstream version 0.25.0

Make sure we take filter and unsuspiciaus texts from debian folder

This was added because these files will be present under .git/dgit/unpack if we
use dgit to push source.

Audit unsuspicious files for 0.25.0 release.

Filter out git test data from libgit2-sys.

Auto merge of #4999 - alexcrichton:beta-next, r=alexcrichton

[beta] Fix `RUSTC=./relative-path` when building

This is a backport of https://github.com/rust-lang/cargo/pull/4995

Fix `RUSTC=./relative-path` when building

This commit adjusts the compiler location logic to resolve `./relative-path`
before invoking rustc to ensure it's no longer cwd-relative. This is how many
other variables like `CARGO_HOME` work, so it's applying similar logic.

Release 0.24.0-1 to Debian unstable.

Prepare 0.24.0 for experimental.

Add lintian-override to ignore false positive from lintian.

Track rustfmt.toml on top level copyright section.

Update copyright file for 0.24.0 release.

Fix the bad_git_dependency test failure.

Auto merge of #4940 - ehuss:ws-meta-beta, r=alexcrichton

Add workspace root to metadata command.

Fixes #4933

Merge of #4938 for rust 1.24 beta.

@alexcrichton I'm uncertain about the process for merging in beta.  I'm guessing after this I just need to open a PR on the rust beta branch to update the cargo submodule?

Add workspace root to metadata command.

Fixes #4933

Update changelog

Comment out copying out Cargo.lock its no longer shipped by upstream.

Mark package as compliant with Debian Policy 4.1.3

Drop url specific hunk from 1002 its merged upstream.

Refresh 2001 for new version of libgit2-sys.

Update upstream source from tag 'upstream/0.24.0'

Update to upstream version '0.24.0'
with Debian dir 902794871ac6926951d065a9f060aedd4bdb04cd

New upstream version 0.24.0

Add files from new vendor to unsuspicious list.

filter out windows related .a files.

Auto merge of #4876 - MaloJaffre:flate2, r=alexcrichton

Upgrade flate2 crate to 1.0 in cargotest

I've missed this part in my previous PR, sorry.
Unblocks rust#46278.

Upgrade flate2 crate to 1.0 in cargotest

I've missed this part in my previous PR, sorry.
Unblocks rust#46278.

Auto merge of #4872 - MaloJaffre:flate-1.0, r=alexcrichton

Upgrade flate2 crate to 1.0

Unblocks rust-lang/rust#46278.

Upgrade flate2 crate to 1.0

Unblocks rust#46278.

Auto merge of #4871 - fschutt:master, r=matklad

Update cargo tests for https://github.com/rust-lang/rust/pull/47052

This test message currently breaks the build. The old error message was:

```
error: could not exec the linker `cc`: No such file or directory (os error 2)
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "hello.hello0.rcgu.o" "hello.hello1.rcgu.o" "-o" "hello" "hello.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-d3700976135c3f09.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-8a207564cfc9f224.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-4712d699ce2d50e5.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-7224935811a361fe.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-3343c92f30e63266.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-6e8aafa8bd1a67de.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-a8b7c0565b6366c3.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-512049fc390dec2e.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-ba1f12eb6cef9a1a.rlib" "/home/felix/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-53aab67ab6317c59.rlib" "-Wl,-Bdynamic" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" "-l" "util"

error: aborting due to previous error
```

The new error message is:

```
error: linker `cc` not found
  |
  = note: No such file or directory (os error 2)

error: aborting due to previous error
```

This currently breaks https://github.com/rust-lang/rust/pull/47052.

**NOTE:** I don't know if I handled the "ticks" around the linker name correctly (if cargo test is smart enough to see that the ticks are part of the omitted part). My reasoning was that in the rustc code the ticks are in the source and not part of the linkers name - so if rustc changes, this will probably break again.

EDIT: fixed error message

Update cargo tests for https://github.com/rust-lang/rust/pull/47052

Auto merge of #4859 - alexcrichton:better-test-fail, r=alexcrichton

Write invalid data when cloning to force an abort

Otherwise it seems libgit2 isn't ready to handle premature eof? Unclear...

Write invalid data when cloning to force an abort

Otherwise it seems libgit2 isn't ready to handle premature eof? Unclear...

Auto merge of #4857 - alexcrichton:better-test-fail, r=alexcrichton

Make the `failed_submodule_checkout` test more robust

Hopefully should help diagnose deadlocks in rust-lang/rust

Make the `failed_submodule_checkout` test more robust

Hopefully should help diagnose deadlocks in rust-lang/rust

Auto merge of #4852 - jtgeibel:cargo-install-target-dir, r=alexcrichton

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.

/cc @alexcrichton, @ishanjain28

Auto merge of #4856 - alexcrichton:no-revoke, r=alexcrichton

Forcibly remove CARGO_HTTP_CHECK_REVOKE when testing

This'll tweak error messages and cause tests to fail

Forcibly remove CARGO_HTTP_CHECK_REVOKE when testing

This'll tweak error messages and cause tests to fail

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 #4851 - sfackler:verify-in-target, r=alexcrichton

Untar into the right dir when verifying

We'd previously dump it in the package's directory which is wrong when
working in a workspace.

Closes #4304

r? @alexcrichton

Untar into the right dir when verifying

We'd previously dump it in the package's directory which is wrong when
working in a workspace.

Closes #4304

Auto merge of #4817 - alexcrichton:incremental-by-default, r=matklad

Enable incremental by default

This commit enables incremental compilation by default in Cargo for all
dev-related profiles (aka anything without `--release` or `bench`. A
number of new configuration options were also added to tweak how
incremental compilation is exposed and/or used:

* A `profile.dev.incremental` field is added to `Cargo.toml` to disable
  it on a per-project basis (in case of bugs).
* A `build.incremental` field was added in `.cargo/config` to disable
  globally (or enable if we flip this default back off).

Otherwise `CARGO_INCREMENTAL` can still be used to configure one
particular compilation. The global `build.incremental` configuration
cannot currently be used to enable it for the release profile.

Enable incremental by default

This commit enables incremental compilation by default in Cargo for all
dev-related profiles (aka anything without `--release` or `bench`. A
number of new configuration options were also added to tweak how
incremental compilation is exposed and/or used:

* A `profile.dev.incremental` field is added to `Cargo.toml` to disable
  it on a per-project basis (in case of bugs).
* A `build.incremental` field was added in `.cargo/config` to disable
  globally (or enable if we flip this default back off).

Otherwise `CARGO_INCREMENTAL` can still be used to configure one
particular compilation. The global `build.incremental` configuration
cannot currently be used to enable it for the release profile.

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

Prepare upload to unstable.

Mark package as compliant with Debian Policy 4.1.2.

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 #4781 - alexcrichton:beta-next, r=alexcrichton

[beta] Reconfigure curl handles after reset

This is a backport of https://github.com/rust-lang/cargo/pull/4780