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

Auto merge of #5000 - Eh2406:i4347, r=alexcrichton

backtrack if can not activate

This is a fix for #4347
Unfortunately this too regressed error messages for the case that you specified a dependency feature that does not  exist.
@alexcrichton advice on improving the message?

Auto merge of #5103 - alexcrichton:no-hamcrest, r=matklad

Drop outdated hamcrest dependency

This hasn't been updated in awhile and in general we've been barely using it.
This drops the outdated dependency and vendors a small amount of the
functionality that it provided. I think eventually we'll want to transition away
from this method of assertions but I wanted to get this piece in to avoid too
much churn in one commit.

Drop outdated hamcrest dependency

This hasn't been updated in awhile and in general we've been barely using it.
This drops the outdated dependency and vendors a small amount of the
functionality that it provided. I think eventually we'll want to transition away
from this method of assertions but I wanted to get this piece in to avoid too
much churn in one commit.

fix cause and the error messages

Fold cargotest into testsuite

Now that there's only one crate with integration tests there's no need to have
this be a separate crate, yay!

One more todo to fix

fix the todo's

needs a test where we have an activation_error the then try activate something that dose not work and backtrack to where we had the activation_error then:
- Hit fast backtracking that go past the crate with the missing features
- Or give a bad error message that does not mention the activation_error.
The test will pass, but there is code that is not yet justified by tests

WIP: make it recurs if activation fails

add a test for cargo/issues/4347

Auto merge of #5093 - alexcrichton:include-cargo-lock, r=matklad

Package lock files in published crates

Previously we had logic to explicitly skip lock files but there's actually a
good case to read these from crates.io (#2263) so let's do so!

Closes #2263

Package lock files in published crates

Previously we had logic to explicitly skip lock files but there's actually a
good case to read these from crates.io (#2263) so let's do so!

Closes #2263

Issue #5087
* targeted error message for virtual manifests
* assert correct error message

Revert "Issue #5087 * fix broken test case"

This reverts commit 17572b8

Issue #5087
* fix broken test case

Auto merge of #5097 - matklad:end-of-tls-saga-hopefully, r=alexcrichton

Revert "Warn Windows 7 users about old TLS"

We now have upgraded libgit2 version, so Cargo would use TLS 1.2
on windows unconditionally. Note that even *unpatched* windows 7
supports TLS 1.2.

@retep998, you've originally written that

>TLS 1.2 support for Windows 7 still requires a rather recent patch and so even if we do fix that, we should still keep this error message because some people use Windows 7 with automatic updates disabled.

However, it looks like Windows 7 **does** support TLS 1.2 out of the box, and the update is required to enable the use of TLS 1.2 by default:

https://github.com/libgit2/libgit2/issues/4546#issuecomment-368909158

My own testing on a random win 7 virtual box confirms this.

closes https://github.com/rust-lang/cargo/issues/5066

Revert "Warn Windows 7 users about old TLS"

We now have upgraded libgit2 version, so Cargo would use TLS 1.2
on windows unconditionally. Note that even *unpatched* windows 7
supports TLS 1.2

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

Respect lock files in crates.io crates

Currently Cargo doesn't publish lock files in crates.io crates but we'll
eventually be doing so, so this changes Cargo to recognize `Cargo.lock` when
it's published to crates.io as use it as the basis for resolution during `cargo
install`.

cc #2263

Auto merge of #5091 - alexcrichton:update-git2, r=matklad

Update git2 to 0.7.0

cc #5066

Update git2 to 0.7.0

cc #5066

Auto merge of #5070 - Eh2406:clippy, r=alexcrichton

Some Clippy suggestions

This is just some suggestions from Clippy and intellij rust.

Clippy still has a lot to say, but this is some of the simple things.

Auto merge of #5059 - tobywhughes:master, r=alexcrichton

Clean with --verbose now prints path of what is being removed.

Added verbose output for the clean command. Simply takes whatever is passed into the rm_rf() function and outputs "Removing /whatever/the/path/to/remove/is"

[Issue this is being used for](https://github.com/rust-lang/cargo/issues/5056)

one more use of entry

some simple clippy things V2

Auto merge of #5081 - matklad:document-not-all-the-things, r=alexcrichton

Support --exclude option for `cargo doc`

I think this should have been implemented when the feature was added for
other commands. Probably just an oversight.

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

r? @alexcrichton

Merge remote-tracking branch 'upstream/master'

Added tests for clean with verbose output

use entry to not hash twice thanks clippy

(cherry picked from commit de9a7b9)

intellij rust suggested fixes

(cherry picked from commit 24836e9)

Auto merge of #5083 - matklad:Cargo-the-tool-1.0, r=alexcrichton

Make cargo-the-binary version the same as the Rust version

Closes #4211 which seems stuck :-)

Soooo, this is the simplest possible fix to this problem:

```
~/projects/cargo Cargo-the-tool-1.0
λ rustc --version
rustc 1.24.0 (4d90ac38c 2018-02-12)

~/projects/cargo Cargo-the-tool-1.0
λ cargo --version
cargo 0.25.0 (8c93e0895 2018-02-01)
```

It makes `cargo --version` to print the corresponding Rust version (with possibly cargo-specific patch number), while keeping the library version the same as today.

On the one hand, this is horrible. On the other hand, it seems to do the job? In the long term, it would be cool skip one version bump for the library, so that `0.x` corresponds to `1.x`.

cc @rust-lang/cargo

I am not sure that this is good idea, the implementation certainly feels horrible :)

Auto merge of #5069 - matklad:win7-y-u-no-tls, r=alexcrichton

Warn Windows 7 users about old TLS

An eyepatch for https://github.com/rust-lang/cargo/issues/5066.

@retep998 what would the best way to check for windows 7 specifically? Currently I use just `#[cfg(windows)]`, which might give false positives on 8 and 10.

Make cargo-the-binary version the same as the Rust version

Closes #4211

Auto merge of #5080 - matklad:hope-this-wont-be-re-reverted, r=alexcrichton

Revert "Seperate licenses with a `/`"

This reverts commit 1ddba76a0f5f83884d20be97f49452f9dd1897f1.

OR is the more modern form :rofl:

r? @alexcrichton

Support --exclude option for `cargo doc`

I think this should have been implemented when the feature was added for
other commands. Probably just an oversight.