Auto merge of #2467 - tshepang:rustfmt, r=alexcrichton

run rustfmt on core/source.rs

Auto merge of #2480 - alexcrichton:ui, r=alexcrichton

Tweak UI for warnings and errors

Right now Cargo prints out errors justified like all other status messages, but
this can look odd without coloration:

```
   error some error message
```

Instead, this commit changes both warnings and errors to use the same style of:

```
error: some error message
warning: some warning message
```

Additionally, warnings now only print out "warning" in yellow instead of the
entire message (like errors do)

Tweak UI for warnings and errors

Right now Cargo prints out errors justified like all other status messages, but
this can look odd without coloration:

```
   error some error message
```

Instead, this commit changes both warnings and errors to use the same style of:

```
error: some error message
warning: some warning message
```

Additionally, warnings now only print out "warning" in yellow instead of the
entire message (like errors do)

run rustfmt on core/source.rs

Includes manual adjustments

Auto merge of #2486 - alexcrichton:flock, r=brson

Fix running Cargo concurrently

Cargo has historically had no protections against running it concurrently. This
is pretty unfortunate, however, as it essentially just means that you can only
run one instance of Cargo at a time **globally on a system**.

An "easy solution" to this would be the use of file locks, except they need to
be applied judiciously. It'd be a pretty bad experience to just lock the entire
system globally for Cargo (although it would work), but otherwise Cargo must be
principled how it accesses the filesystem to ensure that locks are properly
held. This commit intends to solve all of these problems.

A new utility module is added to cargo, `util::flock`, which contains two types:

* `FileLock` - a locked version of a `File`. This RAII guard will unlock the
  lock on `Drop` and I/O can be performed through this object. The actual
  underlying `Path` can be read from this object as well.
* `Filesystem` - an unlocked representation of a `Path`. There is no "safe"
  method to access the underlying path without locking a file on the filesystem
  first.

Built on the [fs2] library, these locks use the `flock` system call on Unix and
`LockFileEx` on Windows. Although file locking on Unix is [documented as not so
great][unix-bad], but largely only because of NFS, these are just advisory, and
there's no byte-range locking. These issues don't necessarily plague Cargo,
however, so we should try to leverage them. On both Windows and Unix the file
locks are released when the underlying OS handle is closed, which means that
if the process dies the locks are released.

Cargo has a number of global resources which it now needs to lock, and the
strategy is done in a fairly straightforward way:

* Each registry's index contains one lock (a dotfile in the index). Updating the
  index requires a read/write lock while reading the index requires a shared
  lock. This should allow each process to ensure a registry update happens while
  not blocking out others for an unnecessarily long time. Additionally any
  number of processes can read the index.
* When downloading crates, each downloaded crate is individually locked. A lock
  for the downloaded crate implies a lock on the output directory as well.
  Because downloaded crates are immutable, once the downloaded directory exists
  the lock is no longer needed as it won't be modified, so it can be released.
  This granularity of locking allows multiple Cargo instances to download
  dependencies in parallel.
* Git repositories have separate locks for the database and for the project
  checkout. The datbase and checkout are locked for read/write access when an
  update is performed, and the lock of the checkout is held for the entire
  lifetime of the git source. This is done to ensure that any other Cargo
  processes must wait while we use the git repository. Unfortunately there's
  just not that much parallelism here.
* Binaries managed by `cargo install` are locked by the local metadata file that
  Cargo manages. This is relatively straightforward.
* The actual artifact output directory is just globally locked for the entire
  build. It's hypothesized that running Cargo concurrently in *one directory* is
  less of a feature needed rather than running multiple instances of Cargo
  globally (for now at least). It would be possible to have finer grained
  locking here, but that can likely be deferred to a future PR.

So with all of this infrastructure in place, Cargo is now ready to grab some
locks and ensure that you can call it concurrently anywhere at any time and
everything always works out as one might expect.

One interesting question, however, is what does Cargo do on contention? On one
hand Cargo could immediately abort, but this would lead to a pretty poor UI as
any Cargo process on the system could kick out any other. Instead this PR takes
a more nuanced approach.

* First, all locks are attempted to be acquired (a "try lock"). If this
  succeeds, we're done.
* Next, Cargo prints a message to the console that it's going to block waiting
  for a lock. This is done because it's indeterminate how long Cargo will wait
  for the lock to become available, and most long-lasting operations in Cargo
  have a message printed for them.
* Finally, a blocking acquisition of the lock is issued and we wait for it to
  become available.

So all in all this should help Cargo fix any future concurrency bugs with file
locking in a principled fashion while also allowing concurrent Cargo processes
to proceed reasonably across the system.

[fs2]: https://github.com/danburkert/fs2-rs
[unix-bad]: http://0pointer.de/blog/projects/locking.html

Closes #354

Fix running Cargo concurrently

Cargo has historically had no protections against running it concurrently. This
is pretty unfortunate, however, as it essentially just means that you can only
run one instance of Cargo at a time **globally on a system**.

An "easy solution" to this would be the use of file locks, except they need to
be applied judiciously. It'd be a pretty bad experience to just lock the entire
system globally for Cargo (although it would work), but otherwise Cargo must be
principled how it accesses the filesystem to ensure that locks are properly
held. This commit intends to solve all of these problems.

A new utility module is added to cargo, `util::flock`, which contains two types:

* `FileLock` - a locked version of a `File`. This RAII guard will unlock the
  lock on `Drop` and I/O can be performed through this object. The actual
  underlying `Path` can be read from this object as well.
* `Filesystem` - an unlocked representation of a `Path`. There is no "safe"
  method to access the underlying path without locking a file on the filesystem
  first.

Built on the [fs2] library, these locks use the `flock` system call on Unix and
`LockFileEx` on Windows. Although file locking on Unix is [documented as not so
great][unix-bad], but largely only because of NFS, these are just advisory, and
there's no byte-range locking. These issues don't necessarily plague Cargo,
however, so we should try to leverage them. On both Windows and Unix the file
locks are released when the underlying OS handle is closed, which means that
if the process dies the locks are released.

Cargo has a number of global resources which it now needs to lock, and the
strategy is done in a fairly straightforward way:

* Each registry's index contains one lock (a dotfile in the index). Updating the
  index requires a read/write lock while reading the index requires a shared
  lock. This should allow each process to ensure a registry update happens while
  not blocking out others for an unnecessarily long time. Additionally any
  number of processes can read the index.
* When downloading crates, each downloaded crate is individually locked. A lock
  for the downloaded crate implies a lock on the output directory as well.
  Because downloaded crates are immutable, once the downloaded directory exists
  the lock is no longer needed as it won't be modified, so it can be released.
  This granularity of locking allows multiple Cargo instances to download
  dependencies in parallel.
* Git repositories have separate locks for the database and for the project
  checkout. The datbase and checkout are locked for read/write access when an
  update is performed, and the lock of the checkout is held for the entire
  lifetime of the git source. This is done to ensure that any other Cargo
  processes must wait while we use the git repository. Unfortunately there's
  just not that much parallelism here.
* Binaries managed by `cargo install` are locked by the local metadata file that
  Cargo manages. This is relatively straightforward.
* The actual artifact output directory is just globally locked for the entire
  build. It's hypothesized that running Cargo concurrently in *one directory* is
  less of a feature needed rather than running multiple instances of Cargo
  globally (for now at least). It would be possible to have finer grained
  locking here, but that can likely be deferred to a future PR.

So with all of this infrastructure in place, Cargo is now ready to grab some
locks and ensure that you can call it concurrently anywhere at any time and
everything always works out as one might expect.

One interesting question, however, is what does Cargo do on contention? On one
hand Cargo could immediately abort, but this would lead to a pretty poor UI as
any Cargo process on the system could kick out any other. Instead this PR takes
a more nuanced approach.

* First, all locks are attempted to be acquired (a "try lock"). If this
  succeeds, we're done.
* Next, Cargo prints a message to the console that it's going to block waiting
  for a lock. This is done because it's indeterminate how long Cargo will wait
  for the lock to become available, and most long-lasting operations in Cargo
  have a message printed for them.
* Finally, a blocking acquisition of the lock is issued and we wait for it to
  become available.

So all in all this should help Cargo fix any future concurrency bugs with file
locking in a principled fashion while also allowing concurrent Cargo processes
to proceed reasonably across the system.

[fs2]: https://github.com/danburkert/fs2-rs
[unix-bad]: http://0pointer.de/blog/projects/locking.html

Closes #354

Auto merge of #2490 - alexcrichton:rustflags-docs, r=alexcrichton

Add docs for RUSTFLAGS and build.rustflags

Auto merge of #2484 - alexcrichton:fix-bad-backtrack, r=brson

Fix caching features across backtracking

In the local loop during resolution all variables need to be reset whenever we
backtrack up a frame, but currently the `method` and `features` set are
accidentally not reset whenever we backtrack. Calculate the `method` later and
cache `features` in each frame so we can properly backtrack.

Closes #2472

Add docs for RUSTFLAGS and build.rustflags

Auto merge of #2241 - brson:rustflags, r=alexcrichton

Apply RUSTFLAGS arguments to rustc builds

Cargo will use RUSTFLAGS for building everything that is not a build script
or plugin. It does not apply to these targets because they may be for
a different platform that 'normal' builds.

Closes #2112

Fix caching features across backtracking

In the local loop during resolution all variables need to be reset whenever we
backtrack up a frame, but currently the `method` and `features` set are
accidentally not reset whenever we backtrack. Calculate the `method` later and
cache `features` in each frame so we can properly backtrack.

Closes #2472

Add rustflags support to config files

`build.rustflags` is treated exactly like `RUSTFLAGS`.

It is a list, so argument lists with spaces work.

`RUSTFLAGS` takes precedent, then `build.rustflags`.

Recompile when RUSTFLAGS changes

Apply RUSTFLAGS env var to rustc builds

This passes RUSTFLAGS to rustc builds for the target architecture.

We don't want to pass the RUSTFLAGS args to multiple architectures because
they may contain architecture-specific flags. Ideally, the scheme
we would use would treat plugins and build scripts - which may not
be for the target architecture - consistently. Unfortunately it's
quite difficult in the current Cargo architecture to seperately
identify build scripts, plugins and their dependencies from
code used by the target.

So the scheme here is very simple:

1) If --target is not specified, RUSTFLAGS applies to all builds.
2) If --target is specified, RUSTFLAGS only applies to builds
   with the Kind::Target target kind, which indicates build units
   derived from the requested --target.

Closes #2112

Auto merge of #2485 - japaric:no-cross-doctests, r=alexcrichton

don't build/run doctests when target != host

fixes rust-lang/rust#31907

r? @alexcrichton

remove unused format argument

update output of cross_tests

don't build/run doctests when target != host

fixes rust-lang/rust#31907

Auto merge of #2483 - srinivasreddy:docs, r=alexcrichton

corrected statement regarding constraint graph solving problem type

corrected statement regarding constraintgraph solving problem type

Auto merge of #2481 - jespino:add-favicon-to-doc, r=alexcrichton

Add favicon to doc.crates.io

This fix the issue rust-lang/crates.io#245

Auto merge of #2468 - TheNeikos:add-warning_if_no_browser, r=alexcrichton

Add warning if no browser

Closes #2371

I am unsure if `println!` is the correct way to print warnings at this stage, since it is not a hard error thus returning `Err` seems a bit too strong.

Add favicon to doc.crates.io

Don't include env in windows/macos

Auto merge of #2474 - sbeckeriv:add-some-flair, r=alexcrichton

Add build flair

Dearest Reviewer

I have add the travis-ci build badge to the README. I pushed the image down towards the bottom. I was thinking that most people reading the readme do not care about the build status. I have seen the badge done in different locations and with different titles. I am easy on where it goes. I added it because I found that I was looking for the status when my branch was failing. I have since learned the travis interface.

<3 Becker

<img width="415" alt="screen shot 2016-03-12 at 10 51 43 am" src="https://cloud.githubusercontent.com/assets/12170/13724615/7fe41e36-e840-11e5-8815-3ac1f13dc2fd.png">

Add flair to readme

Add the travis-ci and appveyor build badges to the readme

Auto merge of #2421 - sbeckeriv:decolor-messages-426, r=alexcrichton

Dull the errors

This resolves #426

Dearest Reviewer,

I have updated the error messages to use say_status at the shell level. I have also changed say_status to print the message in bold. I do think it looks nice but it does have the side effect of making some seemingly unrelated text bold. I do think it looks better bold but it is also very easy to revert. I have included examples of both.

Thank you,
Becker

Bold: Note the usage is bold.
<img width="1072" alt="screen shot 2016-02-27 at 10 49 05 am" src="https://cloud.githubusercontent.com/assets/12170/13374778/0efd54ec-dd43-11e5-9f02-f0224608132a.png">

No bold:
<img width="885" alt="screen shot 2016-02-27 at 10 46 35 am" src="https://cloud.githubusercontent.com/assets/12170/13374775/fa3a6612-dd42-11e5-9c09-8f23506f5f0c.png">

Both rendered on a mac with iterm 2.9.0

Remove color from the errors

I updated the error states to use say_status.
Add text to the empty error
The empty error looked odd with the say_status change.
Update all stderr messages
Switch them to format statements and create a helper for the error
status.

Auto merge of #2473 - alexcrichton:update-curl, r=alexcrichton

Update curl dependency

Fixes a segfault on nightly

Update curl dependency

Fixes a segfault on nightly

Ignore $BROWSER if not set

Show a list of tried browsers in the warning

Auto merge of #2471 - alexcrichton:install-git-lockfile, r=brson

Fix installing git repos with lockfiles

Just an erroneous assertion that needs to be ignored.

Closes #2466

Auto merge of #2454 - alexcrichton:less-recurse, r=brson

Globally optimize traversal in resolve

Currently when we're attempting to resolve a dependency graph we locally
optimize the order in which we visit candidates for a resolution (most
constrained first). Once a version is activated, however, it will add a whole
mess of new dependencies that need to be activated to the global list, currently
appended at the end.

This unfortunately can lead to pathological behavior. By always popping from the
back and appending to the back of pending dependencies, super constrained
dependencies in the front end up not getting visited for quite awhile. This in
turn can cause Cargo to appear to hang for quite awhile as it's so aggressively
backtracking.

This commit switches the list of dependencies-to-activate from a `Vec` to a
`BinaryHeap`. The heap is sorted by the number of candidates for each
dependency, with the least candidates first. This ends up massively cutting down
on resolution times in practice whenever `=` dependencies are encountered
because they are resolved almost immediately instead of way near the end if
they're at the wrong place in the graph.

This alteration in traversal order ended up messing up the existing cycle
detection, so that was just removed entirely from resolution and moved to its
own dedicated pass.

Closes #2090

Auto merge of #2470 - alexcrichton:better-path-error-message, r=brson

Improve the error message for missing path overrides

Closes #2457

Fix installing git repos with lockfiles

Just an erroneous assertion that needs to be ignored.

Closes #2466

Improve the error message for missing path overrides

Closes #2457

Warn if could not open docs in browser

Add $BROWSER as possible client

Auto merge of #2448 - alexcrichton:docs-dirty, r=brson

Fix rerunning rustdoc when output deleted

If `crate/index.html` is missing, we need to rerun rustdoc!

Closes #2379

Auto merge of #2420 - alexcrichton:different-metadata, r=brson

Ensure metadata for libs/bins are distinct

It may be the case in the future that the compiler will require that the "salt"
(the `-C metadata` flag) for all crates with the same name are distinct. Right
now a Cargo project with a library and a binary, however, will have the same
salt with the same crate name.

This commit mixes in some extra data to the library's salt to ensure that its
symbols don't clash with the binary's.

Auto merge of #2460 - jespino:add-limit-to-autocomplete, r=alexcrichton

Add the --limit parameter to search autocomplete

Auto merge of #2461 - jespino:adding-manpages-info, r=alexcrichton

Add search command to the manpage

Add search command to the manpage

Add the --limit parameter to search autocomplete

Auto merge of #2456 - jespino:remove-deprecated-code, r=alexcrichton

Remove deprecated usage of SliceConcatExt::connect

I think this can be changed to .join (the deprecation was in the 1.3 version)

Auto merge of #2455 - jespino:remove-completed-todo, r=alexcrichton

Removing finished TODO

I think this TODO is finished (The only public field in all the file is the Layout::path) If this is part of the TODO, i can set it as private and create a getter).

Remove deprecated usage of SliceConcatExt::connect

Removing finished TODO

Globally optimize traversal in resolve

Currently when we're attempting to resolve a dependency graph we locally
optimize the order in which we visit candidates for a resolution (most
constrained first). Once a version is activated, however, it will add a whole
mess of new dependencies that need to be activated to the global list, currently
appended at the end.

This unfortunately can lead to pathological behavior. By always popping from the
back and appending to the back of pending dependencies, super constrained
dependencies in the front end up not getting visited for quite awhile. This in
turn can cause Cargo to appear to hang for quite awhile as it's so aggressively
backtracking.

This commit switches the list of dependencies-to-activate from a `Vec` to a
`BinaryHeap`. The heap is sorted by the number of candidates for each
dependency, with the least candidates first. This ends up massively cutting down
on resolution times in practice whenever `=` dependencies are encountered
because they are resolved almost immediately instead of way near the end if
they're at the wrong place in the graph.

This alteration in traversal order ended up messing up the existing cycle
detection, so that was just removed entirely from resolution and moved to its
own dedicated pass.

Closes #2090

Auto merge of #2450 - jespino:remove-unwraps-crates-io, r=alexcrichton

Remove unwraps from crates-io lib

Auto merge of #2449 - jespino:multiple-search-params, r=alexcrichton

Multiple search params

Allow multiple search query params

Remove unwraps from crates-io lib

Auto merge of #2444 - jespino:issue-2402-2, r=alexcrichton

Adding --limit usage suggestion on search results (#2402)

Adding --limit usage suggestion on search results (#2402)

Fix rerunning rustdoc when output deleted

If `crate/index.html` is missing, we need to rerun rustdoc!

Closes #2379

Auto merge of #2435 - alexcrichton:docs, r=alexcrichton

The API docs for Cargo live at doc.crates.io/cargo, not doc.crates.io in
general.

Auto merge of #2439 - jespino:issue-2402, r=alexcrichton

Add limit parameter to search command (fix issue #2402)

Auto merge of #2438 - jseyfried:subcommands, r=alexcrichton

This PR moves the subcommands in `src/bin` into their own directory and ensures future compatibility with the corrected search paths for non-inline modules (see [Rust PR #32006](https://github.com/rust-lang/rust/pull/32006)).
r? @alexcrichton

Ensure future compatibility with fixed module search paths (see rust PR #32006)

Auto merge of #2423 - alexcrichton:fix-pkgid-hash, r=brson

All crates being compiled by Cargo are identified by a unique `PackageId` instance. This ID incorporates information such as the name, version, and source from where the crate came from. Package ids are allowed to have path sources to depend on local crates on the filesystem. The package id itself encodes the path of where the crate came from.

Historically, however, the "path source" from where these packages are learned had some interesting logic. Specifically one specific source would be able to return many packages within. In other words, a path source would recursively walk crate definitions and the filesystem attempting to find crates. Each crate returned from a source has the same source id, so consequently all packages from one source path would have the same source path id.

This in turn leads to confusing an surprising behavior, for example:

* When crates are compiled the status message indicates the path of the crate root, not the crate being compiled
* When viewed from two different locations (e.g. two different crate roots) the same package would have two different source ids because the id is based on the root location.

This hash mismatch has been [papered over](https://github.com/rust-lang/cargo/pull/1697) in the past to try to fix some spurious recompiles, but it unfortunately [leaked back in](https://github.com/rust-lang/cargo/pull/2279). This is clearly indicative of the "hack" being inappropriate so instead these commits fix the root of the problem.

---

In short, these commits ensure that the package id for a package defined locally has a path that points precisely at that package. This was a relatively invasive change and had ramifications on a few specific portions which now require a bit of extra code to support.

The fundamental change here was to change `PathSource` to be non-recursive by default in terms of what packages it thinks it contains. There are still two recursive use cases, git repositories and path overrides, which are used for backwards compatibility. This meant, however, that the packaging step for crate no longer has knowledge of other crates in a repository to filter out files from. Some specific logic was added to assist in discovering a git repository as well as filtering out sibling packages.

Another ramification of this patch, however, is that special care needs to be taken when decoding a lockfile. We now need all path dependencies in the lockfile to point precisely at where the path dependency came from, and this information is not encoded in the lock file. The decoding support was altered to do a simple probe of the filesystem to recursively walk path dependencies to ensure that we can match up packages in a lock file to where they're found on the filesystem.

Overall, however, this commit closes #1697 and also addresses servo/servo#9794 where this issue was originally reported.

Add a regression test for the issue being fixed

When compiling a package from two separate locations it should be cached the
same way both times.

Fix all tests with recent changes

The package id for path dependencies now has another path component pointing
precisely to the package being compiled, so lots of tests need their output
matches to get updated.

Fix some packaging logic in path sources

Currently the packaging logic depends on the old recursive nature of path
sources for a few points:

* Discovery of a git repository of a package.
* Filtering out of sibling packages for only including the right set of files.

For a non-recursive path source (now essentially the default) we can no longer
assume that we have a listing of all packages. Subsequently this logic was
tweaked to allow:

* Instead of looking for packages at the root of a repo, we instead look for a
  Cargo.toml at the root of a git repository.
* We keep track of all Cargo.toml files found in a repository and prune out all
  files which appear to be ancestors of that package.

Fix decoding lock files with path dependencies

With the previous changes a path dependency must have the precise path to it
listed in its package id. Currently when decoding a lockfile, however, all path
dependencies have the same package id, which unfortunately causes a mismatch.

This commit alters the decoding of a lockfile to perform some simple path
traversals to probe the filesystem to understand where path dependencies are and
set the right package id for the found packages.

Ensure overrides use recursive path sources

This mirrors the behavior that they have today. The `load` method for path
sources will by default return a non-recursive `PathSource` which unfortunately
isn't what we want here.

Remove hacks when hashing package ids

Right now there's a few hacks here and there to "correctly" hash package ids by
taking a package's root path into account instead of the path store in the
package id. The purpose of this was to solve issues where the same package
referenced from two locations ended up having two different hashes.

This hack leaked, however, into the implementation of fingerprints which in
turned ended up causing spurious rebuilds. Fix this problem once and for all by
just defining hashing on package ids the natural and expected way.

Remove usage of PathSource::for_path

This does much more I/O than Package::for_path and this is also on its way out.

Update documentation link for API docs

The API docs for Cargo live at doc.crates.io/cargo, not doc.crates.io in
general.

Auto merge of #2434 - alexcrichton:bump, r=brson

Bump to 0.10.0

Auto merge of #2433 - alexcrichton:fix-lines-match, r=alexcrichton

Right now we only match a suffix of the line, assuming all lines start with
`[..]`. Instead this ensures that the first match is anchored at the start.

Fix output matching in tests

Right now we only match a suffix of the line, assuming all lines start with
`[..]`. Instead this ensures that the first match is anchored at the start.

Auto merge of #2430 - birkenfeld:doc-menu, r=alexcrichton

crates.io pull request: https://github.com/rust-lang/crates.io/pull/276

Doc header: change Documentation to Docs to conform with PR to crates.io

Auto merge of #2406 - alexcrichton:download-less, r=brson

Currently Cargo will download an entire resolution graph all at once when in fact most packages may not be relevant to a compilation. For example target-specific dependencies and dev-dependencies are unconditionally downloaded regardless of whether they're actually needed or not.

This commit alters the internals of Cargo to avoid downloading everything immediately and just switches to lazily downloading packages. This involved adding a new `LazyCell` primitive (similar to the one in use on crates.io) and also propagates `CargoResult` in a few more locations.

Overall this ended up being a pretty large refactoring so the commits are separated in bite-sized chunks as much as possible with the end goal being this PR itself.

Closes #2394

Auto merge of #2419 - dikaiosune:master, r=alexcrichton

Resolves #2417. I also reorganized the order of the items on the page and moved a little bit of text around. I think it's clearer, but critique is more than welcome.

Ensure metadata for libs/bins are distinct

It may be the case in the future that the compiler will require that the "salt"
(the `-C metadata` flag) for all crates with the same name are distinct. Right
now a Cargo project with a library and a binary, however, will have the same
salt with the same crate name.

This commit mixes in some extra data to the library's salt to ensure that its
symbols don't clash with the binary's.

Disambiguating docs about when environment variables are set.
Providing an example of fetching env vars at runtime in a buildscript.
Reordering the list so that examples pertain to the correct sections.

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

This crate was recently updated to the next release of libgit2, and I've noticed
historically that a noop `cargo build` was slow in the git2-rs repository.
Curious to see if the new libgit2 version helped speed things up at all, I
tested it out.

Before this commit, a noop `cargo build` produced 599108 syscalls. After this
commit, a noop build produced 86925 syscalls, an 85% reduction in the number of
syscalls! Needless to say it's much faster.

Update dependency on git2

This crate was recently updated to the next release of libgit2, and I've noticed
historically that a noop `cargo build` was slow in the git2-rs repository.
Curious to see if the new libgit2 version helped speed things up at all, I
tested it out.

Before this commit, a noop `cargo build` produced 599108 syscalls. After this
commit, a noop build produced 86925 syscalls, an 85% reduction in the number of
syscalls! Needless to say it's much faster.

Auto merge of #2397 - alexcrichton:config-verbose, r=brson

This commit adds configuration keys for:

    [term]
    verbose = true
    color = 'auto'

These are all meant to be proxies for the command line flags but configured on a
global basis if desired.

Add configuration keys for -v, --color

This commit adds configuration keys for:

    [term]
    verbose = true
    color = 'auto'

These are all meant to be proxies for the command line flags but configured on a
global basis if desired.

Stop downloading all packages immediately

Instead delay all downloads until just before they're needed. This should ensure
that we don't download any more packages than we really need to.

Auto merge of #2398 - alexcrichton:config-env-var, r=brson

This commit adds a more principled system to rationalize what ends up being a
configuration value versus an environment variable. This problem is solved by
just saying that they're one and the same! Similar to Bundler, this commit
supports overriding the `foo.bar` configuration value with the `CARGO_FOO_BAR`
environment variable.

Currently this is used as part of the `get_string` and `get_i64` methods on
`Config`. This means, for example, that the following environment variables can
now be used to configure Cargo:

* CARGO_BUILD_JOBS
* CARGO_HTTP_TIMEOUT
* CARGO_HTTP_PROXY

Currently it's not supported to encode a list in an environment variable, so for
example `CARGO_PATHS` would not be read when reading the global `paths`
configuration value.

cc #2362
cc #2395 -- intended to close this in tandem with #2397

Auto merge of #2415 - kamalmarhubi:doc-env-var-cargo-manifest-dir, r=alexcrichton

doc: Include CARGO_MANIFEST_DIR as being set for crates

Auto merge of #2411 - sbeckeriv:cargo-cache-doc-update-1609, r=alexcrichton

Per https://github.com/rust-lang/cargo/issues/1609 "clarify how the cache works"

Added in a single line that states that the cached packages are only
removed by running the clean command.

Please let me know if this is the wrong spot, incorrect information or just silly.
Thanks
becker

Auto merge of #2414 - sbeckeriv:document-bit-env-flag-1375, r=alexcrichton

Per https://github.com/rust-lang/cargo/issues/1375

Just add a note around the python script BIT flag.

Fix name

And move line below code block per merge request.

Add a note for the 32 bit flag

Per https://github.com/rust-lang/cargo/issues/1375

Just add a note around the python script flag

Updated text based on pull request

Auto merge of #2407 - alexcrichton:better-failed-auth-error, r=brson

This commit is an attempt to improve the error message from failed
authentication attempts as well as attempting more usernames. Right now we only
attempt one username, but there are four different possible choices we could
select (including $USER which we weren't previously trying).

This commit tweaks a bunch of this logic and just in general refactors the
with_authentication function.

Closes #2399

Auth with more usernames and improve errors

This commit is an attempt to improve the error message from failed
authentication attempts as well as attempting more usernames. Right now we only
attempt one username, but there are four different possible choices we could
select (including $USER which we weren't previously trying).

This commit tweaks a bunch of this logic and just in general refactors the
with_authentication function.

Closes #2399

Auto merge of #2400 - JIghtuse:master, r=alexcrichton

Fixes #2378

Clarify third party subcommand failure error message

Fixes #2378

Add information package caching.

Per https://github.com/rust-lang/cargo/issues/1609
Added in a single line that states that the cached packages are only
removed by running the clean command.

Auto merge of #2369 - alexcrichton:no-more-ar, r=alexcrichton

This is largely no longer needed as we bundle llvm-ar and use that (and it's
cross platform). Note that the underlying support still exists in Cargo as the
flag hasn't been removed from the compiler outright, and older compilers may
still be in use. Just no need to document it so prominently when it's no longer
needed!