Validate that `jobs` argument is a number

Unwind stack for cli errors

Remove dead code

Remove docopt dependency

Fix after rebase

Fix typo

Remove dead code

Fix `--explain`

Support list subcommand

All tests are green :tada:

Support aliases

Fix more tests by updating error messages

Unignore test which now passes

Disable `cargo help -h`

Fix verify-project command

Support built-in aliases

Support external subcommands

Cleanup

Restore global initialization

Use exit code 1 for command line parsing errors

Note that while we use 101 in majority of cases, sometimes we use 1 as
well.

Fix some trivially fixable tests

Drop old commands

Move the rest of the commands to clap

Move uninstall to clap

Move test to clap

Move search to clap

Don't copy-paste index argument

Don't copy-paste package argument

Move rustdoc to clap

Move rustc to clap

Move run to clap

Move read-manifest to clap

Move publish to clap

Move pkgid to clap

Move package to clap

Move owner to clap

Move new to clap

Move metadata to clap

Move login to clap

Move locate-project to clap

Move install to clap

Specify frozen & locked for all commands simultaneously

Move init to clap

Move git-checkout to clap

Move generate-lockfile to clap

Move fetch to clap

Move doc to clap

Move clean to clap

Move check to clap

Temporarly ignore some tests

Port bench and build to clap

Auto merge of #5150 - Eh2406:more_interning, r=alexcrichton

More interning

This is a small part of the unsuccessful last commit of #5121, this part removes `InternedString::new` from the innerest of loops.

This is mostly a resubmission of #5147, that I accidentally deleted while bors was testing. This one has new commits, so github will take the resubition.

intern links attribute

Auto merge of #5147 - Eh2406:restucture, r=alexcrichton

restructure `Activations` for better clone

This builds on the work in #5121 When we last met we had:
5000000 ticks in ~48 sec, 0r 104k ticks/sec
This small change brings us to:
5000000 ticks in ~21 sec, 0r 238k ticks/sec
Edit: sorry for the large diff only the last commit is new. The rest are from #5121

restructure `Activations` for better clone

Auto merge of #5121 - Eh2406:string_interning, r=alexcrichton

String interning

This builds on the work from #5118. This interns the strings in the part of resolver that gets cloned a lot.

In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 1700000 ticks in ~(63 to 67) sec from #5118
After we got to 1700000 ticks in ~(42 to 45) sec

The interning code itself would be much better with a `leak` function that converts a `String` to a `&'static str`. Something like:
```rust
pub fn leek(s: String) -> &'static str {
    let ptr = s.as_ptr();
    let len = s.len();
    mem::forget(s);
    unsafe {
        let slice = slice::from_raw_parts(ptr, len);
        str::from_utf8(slice).unwrap()
    }
}
```
but "there is no unsafe in Cargo", and I am not the best at unsafe. So I just `to_string` and lived with the extra copy. Is there a better way to hand out references?

I assumed that `InternedString::new` world start appearing in profile result, and that we would want `PackageId`, and `Summary`, Et Al. to store the `InternedString`. That is why I put the interner in a shared folder. So far it is just used in the resolver. It may make sense for a lot more of the Strings to be interned, but with the extra copy... I have not explored it yet.

use `Deref` instead of an explicit function

use `into_boxed_str` to shrink before we leek

Auto merge of #5012 - infinity0:pr4988, r=alexcrichton

Don't require dev-dependencies when not needed in certain cases

Specifically, when running `cargo install` and add a flag for this behaviour in `cargo build`.

This closes #4988.

Work around #5134 for now

Auto merge of #5138 - alexcrichton:small-opt, r=matklad

Some small optimizations

Found an easy hot spot or two when profiling `./x.py build` in rust-lang/rust, although certainly still lots remaining.

Retain a vector instead of reallocating

No need to create a new version!

add unsafe

Auto merge of #5135 - matklad:drop-ignored-tests, r=alexcrichton

Drop ignored tests

r? @alexcrichton

These tests are ignored, so its better to remove them. `run` does not supports `--bins` argument, so I've left a single test that checks specifically for this.

cc https://github.com/rust-lang/cargo/pull/3901

Optimize SourceId::crates_io

Turns out this gets called a lot in large projects as almost all dependencies
come from crates.io and parsed manifests use this. Let's cache the result as
it's always the same!

and links just to be throw

intern the features

In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 5000000 ticks in ~65 sec
After we got to 5000000 ticks in ~52 sec

make a global string interner

In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 5000000 ticks in ~72 sec
After we got to 5000000 ticks in ~65 sec

Drop ignored tests

Revert "Make the default behaviour of `cargo build` match the documentation"

This reverts commit 3fc0715d33ccea567526242d2247576930db4a7c.

Auto merge of #5132 - Eh2406:less_clones, r=alexcrichton

don't clone a BacktrackFrame if we are not going to backtrack

I think this is a fix for #5130.

Currently the only recoverable `activate` error does not corrupt `cx`, so this is definitely ok. We should be careful as we add more recoverable `activate` errors that they don't corrupt `cx` to the point where the error messages are affected.

don't clone a BacktrackFrame if we are not going to backtrack

Merge remote-tracking branch 'upstream/master' into pr4988

Auto merge of #5127 - ehuss:incremental-doc, r=alexcrichton

Fix reference docs for "incremental" in the wrong place.

It is part of the [build] section, not a [target].

Fix reference docs for "incremental" in the wrong place.

It is part of the [build] section, not a [target].

Auto merge of #5122 - acmcarther:acm-emit-features-from-cargo-metadata, r=alexcrichton

Emit Resolve.features_sorted in "cargo metadata"

This PR adds `features` to `metadata.resolve.nodes[*]` using the Resolve object's known features. This is different from the `features` fields that already exist elsewhere within metadata as this one is the actual features that need to be used in order to build the code.

Context: I'm currently using Cargo's internals to synthesize BUILD files for the Bazel build tool. `cargo metadata` currently provides almost everything I need in order to avoid using Cargo's internals -- *except* for this.

cc https://github.com/google/cargo-raze/issues/7

Repair the other metadata tests

Emit resolve.features in "cargo metadata"

Auto merge of #5119 - alexcrichton:no-clone-index-in-tests, r=matklad

Update a test to not clone the real index

A local index should work ok!

Update a test to not clone the real index

A local index should work ok!

Auto merge of #5118 - Eh2406:more_rc, r=alexcrichton

use more Rc in the part of resolver that gets cloned a lot

In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 1700000 ticks in ~(82 to 97) sec
After we got to 1700000 ticks in ~(63 to 67) sec

use more Rc in the part of resolver that gets cloned a lot

In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 1700000 ticks in ~(82 to 97) sec
After we got to 1700000 ticks in ~(63 to 67) sec

Auto merge of #5112 - Eh2406:cache_queries, r=alexcrichton

Cache the query result.

Small performance gain.

In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 1700000 ticks in ~97 sec
After we got to 1700000 ticks in ~92 sec. I just reran and got ~82, so it seems to be unstable.
And query disappears from the flame graph

Use `HashMap` insted of `BTreeMap`

`Context` no longer needs replacements nor its lifetime

Make a `RegistryQueryer` to own the cache

Merge remote-tracking branch 'upstream/master' into pr4988

Auto merge of #5110 - alexcrichton:reset-harder, r=matklad

Try a lot harder to recover corrupt git repos

We've received a lot of intermittent bug reports historically about corrupt git
repositories. These inevitably happens as Cargo is ctrl-c'd or for whatever
other reason, and to provide a better user experience Cargo strives to
automatically handle these situations by blowing away the old checkout for a new
update.

This commit adds a new test which attempts to pathologically corrupt a git
database and checkout in an attempt to expose bugs in Cargo. Sure enough there
were some more locations that we needed to handle gracefully for corrupt git
checkouts. Notable inclusions were:

* The `fetch` operation in libgit2 would fail due to corrupt references. This
  starts by adding an explicit whitelist for classes of errors coming out of
  `fetch` to auto-retry by blowing away the repository. We need to be super
  careful here as network errors commonly come out of this function and we don't
  want to too aggressively re-clone.

* After a `fetch` succeeded a repository could fail to actual resolve a
  git reference to the actual revision we want. This indicated that we indeed
  needed to blow everything away and re-clone entirely again.

* When creating a checkout from a database the `reset` operation might fail due
  to a corrupt local database of the checkout itself. If this happens we needed
  to just blow it away and try again.

There's likely more lurking situations where we need to re-clone but I figure we
can discover those over time.

Try a lot harder to recover corrupt git repos

We've received a lot of intermittent bug reports historically about corrupt git
repositories. These inevitably happens as Cargo is ctrl-c'd or for whatever
other reason, and to provide a better user experience Cargo strives to
automatically handle these situations by blowing away the old checkout for a new
update.

This commit adds a new test which attempts to pathologically corrupt a git
database and checkout in an attempt to expose bugs in Cargo. Sure enough there
were some more locations that we needed to handle gracefully for corrupt git
checkouts. Notable inclusions were:

* The `fetch` operation in libgit2 would fail due to corrupt references. This
  starts by adding an explicit whitelist for classes of errors coming out of
  `fetch` to auto-retry by blowing away the repository. We need to be super
  careful here as network errors commonly come out of this function and we don't
  want to too aggressively re-clone.

* After a `fetch` succeeded a repository could fail to actual resolve a
  git reference to the actual revision we want. This indicated that we indeed
  needed to blow everything away and re-clone entirely again.

* When creating a checkout from a database the `reset` operation might fail due
  to a corrupt local database of the checkout itself. If this happens we needed
  to just blow it away and try again.

There's likely more lurking situations where we need to re-clone but I figure we
can discover those over time.

Cache the query result.

In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 1700000 ticks in ~97 sec
After we got to 1700000 ticks in ~92 sec
And query disappears from the flame graph

Auto merge of #5111 - ehuss:bashc-toolchains, r=alexcrichton

Support +toolchain rustup override in bash completions.

Fixes #5107

Support +toolchain rustup override in bash completions.

Fixes #5107

Auto merge of #5095 - tdbgamer:master, r=matklad

Issue #5087

* remove Workspace::current_manifest
* remove incorrect logging
* move empty check to Packages::into_package_id_specs
* add test case mentioned in issue

Auto merge of #5104 - Eh2406:bug_fix, r=alexcrichton

missed this important bug

In the PR #5000 I finished and we merged yesterday I missed a bug and left in an outdated comment.

@alexcrichton

This test should pass if we have tried to `update registry` evan if the command otherwise fails

get ci green; don't clone more than we need

missed this important bug

Merge remote-tracking branch 'upstream/master'

Issue #5087
* change match to if

Auto merge of #5100 - alexcrichton:better-dep-ordering, r=matklad

Improve Cargo's scheduling of builds

Historically Cargo has been pretty naive about scheduling builds, basically just
greedily scheduling as much work as possible. As pointed out in #5014, however,
this isn't guaranteed to always have the best results. If we've got a very deep
dependency tree that would otherwise fill up our CPUs Cargo should ideally
schedule these dependencies first. That way when we reach higher up in the
dependency tree we should have more work available to fill in the cracks if
there's spare cpus.

Closes #5014

Improve Cargo's scheduling of builds

Historically Cargo has been pretty naive about scheduling builds, basically just
greedily scheduling as much work as possible. As pointed out in #5014, however,
this isn't guaranteed to always have the best results. If we've got a very deep
dependency tree that would otherwise fill up our CPUs Cargo should ideally
schedule these dependencies first. That way when we reach higher up in the
dependency tree we should have more work available to fill in the cracks if
there's spare cpus.

Closes #5014