Auto merge of #2679 - sbeckeriv:alias, r=alexcrichton

Command alias or Alias command #1091

Dearest Reviewer,

This pull request closes #1091 which is a request to support aliases.
This is not as powerful as something like git's alias, however, I think
it sticks true to the original request.

I high jack the processing of the args. After a few flags are checked
and the args are parsed I check the config file for alias.COMMAND. If it
is there I split it like args does and replace args[1] (the original
command) with the alias command and its 'flags'.

As an extra measure I output the alias command with warn. I would be
willing to drop that or put it behind a verbose flag. Also the docs have
been updated.

Thanks!
Becker

<img width="784" alt="screen shot 2016-05-12 at 10 23 59 am" src="https://cloud.githubusercontent.com/assets/12170/15226012/d18a3336-1835-11e6-94c9-875a63a79856.png">

Auto merge of #2867 - mattscamp:add_jobs_flag, r=alexcrichton

Add jobs flag to package

https://github.com/rust-lang/cargo/issues/2860

Add jobs flag to package

Auto merge of #2863 - QuiltOS:specified-req, r=alexcrichton

Make the `DependencyInner::specified_req` field a bool.

I could almost get rid if it completely, but then the dependency verifier would have to abort on, say, no version req specified or the any req. Crates.io indeed doesn't want wildcards, but other registries some day may have a different policy.

Making it a mere bool---since all the information it contained is on the `req` field anyways---was the next best thing.

Make the `DependencyInner::specified_req` field a bool.

This field is hardly used. I could almost get rid if it completely, but
then the dependency verifier would have to abort on, say, no version req
specified or the any req. Crates.io indeed doesn't want such wildcards, but
other registries some day may have a different policy.

Making it a mere bool---since all the information it contained is in the
`req` field anyways---was the next best thing.

Auto merge of #2862 - alexcrichton:update-rust, r=alexcrichton

Update the rust nightly to build cargo nightlies

Right now Cargo doesn't work on OSX 10.12, but the fix is in upstream rustc, so
let's pick that up and make Cargo nightlies compatible as well.

Update the rust nightly to build cargo nightlies

Right now Cargo doesn't work on OSX 10.12, but the fix is in upstream rustc, so
let's pick that up and make Cargo nightlies compatible as well.

Auto merge of #2853 - matklad:reduce-duplication, r=alexcrichton

Reduce duplication in `Context` creation

There was some duplicated code for `Context` creation in `cargo_clean` and `cargo_rustc`. I've tried to remove it by moving the common part into `Context::new`. Not sure that this is the right thing to do though, it's just something I came across while tracing `rustc_info` flow.

Additional possible refactoring would be to remove `Default` bound from `BuildConfig`.

Auto merge of #2852 - alexcrichton:doc-env-vars, r=alexcrichton

Document the RUSTC/RUSTDOC build script env vars

Document the RUSTC/RUSTDOC build script env vars

Reduce duplication in `Context` creation

Auto merge of #2830 - munyari:rustc-env, r=alexcrichton

Set environment variable for rustc in custom_build.rs

Addresses #2819

Assert that RUSTC and RUSTDOC are set correctly

Auto merge of #2842 - alx741:update_manpages, r=alexcrichton

Update manpages with new flags

Add the [new flags](http://blog.rust-lang.org/2016/07/07/Rust-1.10.html)

Man pages: add 'force' flag

Man pages: add 'doc' flag

Man pages: add 'explain' flag

Auto merge of #2839 - alexcrichton:same-root, r=brson

Generate the same lock always in a workspace

Previously the "root" of a lock file would erroneously change over time, so
instead just ensure that the root of a lock file is always the root of the
workspace. Otherwise the contents should always be the same.

Closes #2837

Generate the same lock always in a workspace

Previously the "root" of a lock file would erroneously change over time, so
instead just ensure that the root of a lock file is always the root of the
workspace. Otherwise the contents should always be the same.

Closes #2837

Auto merge of #2840 - matklad:remove-dead-code, r=alexcrichton

Remove dead code

Are these functions necessary for some reason?

Remove dead code

Auto merge of #2835 - alexcrichton:bump, r=alexcrichton

Bump to 0.13.0

Bump to 0.13.0

Command alias or Alias command #1091

Dearest Reviewer,

This pull request closes #1091 which is a request to support aliases.
This is not as powerful as something like git's alias, however, I think
it sticks true to the original request.

I high jack the processing of the args. After a few flags are checked
and the args are parsed I check the config file for alias.COMMAND. If it
is there I split it like args does and replace args[1] (the original
command) with the alias command and its 'flags'.

I have also included default short hand commands b, t and r.

Thanks!
Becker

Auto merge of #2815 - alexcrichton:lets-add-some-docs, r=brson

Document the [replace] section

Thought I did this before, but apparently forgot!

Document the [replace] section

Thought I did this before, but apparently forgot!

Set environment variable for rustdoc in custom_build.rs

Auto merge of #2828 - bennofs:cargo-repackage, r=alexcrichton

cargo package: overwrite existing tarballs

Previously, cargo package did not do anything if a tarball already
existed. This is wrong, because the source may have changed and cargo
does not do any dependency tracking for package tarballs yet, so it did
not notice this.

This commit changes cargo package to always overwrite existing tarballs,
which works fine until proper dependency tracking is implemented.

Fixes #2799

Set environment variable for rustc in custom_build.rs

Auto merge of #2829 - brson:doc, r=alexcrichton

Use consistent capitalization in doc headers

There was a pretty even mix of upper-case and lower-case, so I chose lower. This appears to be consistent with other rust docs.

cargo package: overwrite existing tarballs

Previously, cargo package did not do anything if a tarball already
existed. This is wrong, because the source may have changed and cargo
does not do any dependency tracking for package tarballs yet, so it did
not notice this.

This commit changes cargo package to always overwrite existing tarballs,
which works fine until proper dependency tracking is implemented.

Fixes #2799

Auto merge of #2794 - alexcrichton:rustdocflags, r=brson

Add support for RUSTDOCFLAGS

Like with RUSTFLAGS, parse this variable to pass along extra arguments to
invocations of `rustdoc`.

Use consistent capitalization in doc headers

Auto merge of #2759 - alexcrichton:workspaces, r=brson

Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].

Implement workspaces in Cargo

This commit is an implementation of [RFC 1525] which specifies the addition of
**workspaces** to Cargo.

[RFC 1525]: https://github.com/rust-lang/rfcs/blob/master/text/1525-cargo-workspace.md

A workspace is a group of crates which are all compiled into the same output
directory and share the same `Cargo.lock` file. This means that dependencies are
cached between builds as well as dependencies all being shared at the same
versions. An update to any one dependency transitively affects all other members
of the workspace.

Typical repository layouts with a crate at the root and a number of path
dependencies simply need to add the following to the root `Cargo.toml`:

```toml
[workspace]
```

Otherwise more advanced configuration may be necessary through the
`package.workspace` or `workspace.members` keys. More information can be found
as part of [RFC 1525].

Auto merge of #2826 - KaivoAnastetiks:fix/no-subcommand-name, r=alexcrichton

Display the name of the unknown subcommand.

?r @alexcrichton
Fixes #2825

Splits a test on two lines to keep it below 100 chars.

Add a test for invalid subcommand displayed on error.

Display the name of the unknown subcommand.

Auto merge of #2822 - munyari:owner-man, r=alexcrichton

Add owner subcommand to cargo's man page

Addresses #2789

Add man page for owner subcommand

Auto merge of #2821 - bennofs:no-transitive-dep-feature, r=alexcrichton

Disallow specifying features of transitive deps

Before this commit, it was possible to activate a feature in a transtive
dependency, using a Cargo.toml like the following one:

    ...
    [features]
    # this will enable feature fast in package bar, which is a
    # dependency of foo
    default = [ foo/bar/fast ]

This is a bug, and was never intended, and it is checked in other places
already. The behavior was possible because `build_features::add_feature`
treats the specification "foo/bar/fast" as just another feature. So when
we require the feature "foo/bar/fast", add_feature for foo will generate a
dependency on "foo" requiring that feature "bar/fast" is enabled. Then,
when resolving foo, add_feature will find that "bar/fast" is a required
feature, so it'll happily add "fast" as the required feature for the
dependency "foo".

The fix for this is to make sure that the `add_feature` function does
not treat `a/b` specifications as just another feature. Instead, it now
handles that case without recursion directly when it encounters it.

We can see how this resolves the above problem: when resolving foo,
add_feature for the required feature "bar/fast" will be called.
Because add_feature no longer treats such specifciations differently at
the top level, it will try to enable a feature with the exact name
"bar/fast", and Context::resolve_features will later find that no such
feature exists for package foo.

To give a friendlier error message, we also check in
Context::resolve_features that we never ever require a feature with a
slash in a name from a dependency.

Add owner subcommand to cargo's man page

Disallow specifying features of transitive deps

Before this commit, it was possible to activate a feature in a transtive
dependency, using a Cargo.toml like the following one:

    ...
    [features]
    # this will enable feature fast in package bar, which is a
    # dependency of foo
    default = [ foo/bar/fast ]

This is a bug, and was never intended, and it is checked in other places
already. The behavior was possible because `build_features::add_feature`
treats the specification "foo/bar/fast" as just another feature. So when
we require the feature "foo/bar/fast", add_feature for foo will generate a
dependency on "foo" requiring that feature "bar/fast" is enabled. Then,
when resolving foo, add_feature will find that "bar/fast" is a required
feature, so it'll happily add "fast" as the required feature for the
dependency "foo".

The fix for this is to make sure that the `add_feature` function does
not treat `a/b` specifications as just another feature. Instead, it now
handles that case without recursion directly when it encounters it.

We can see how this resolves the above problem: when resolving foo,
add_feature for the required feature "bar/fast" will be called.
Because add_feature no longer treats such specifciations differently at
the top level, it will try to enable a feature with the exact name
"bar/fast", and Context::resolve_features will later find that no such
feature exists for package foo.

To give a friendlier error message, we also check in
Context::resolve_features that we never ever require a feature with a
slash in a name from a dependency.

Auto merge of #2804 - skeleten:master, r=alexcrichton

Add color support for Windows consoles

Unfortunately, the `term` API makes this PR rather inelegant, any hints/pointers to make it better are highly appreciated!

Fixes #2803

Auto merge of #2809 - cardoe:config-updates, r=alexcrichton

respect configure options for paths

This change causes the installed paths of some files to respect the options passed to configure. It additionally adds another option and removes an unused option.

build: add docdir to configure

Add a docdir argument to the configure script to allow distros or users
with non-standard paths to customize the installation as needed.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

build: respect datadir, infodir, mandir, libdir, and sysconfdir

The configure script exposes datadir, infodir, mandir, libdir, and
sysconfdir but then they are unused so distros or users with
non-standard paths are not able to change things as would be expected by
the configure script.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

Merge branch 'master' into master

build: write updated variables to config.mk

Write the CFG_PREFIX stripped CFG_DATADIR, CFG_MANDIR, and CFG_INFODIR
to config.mk

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

build: strip CFG_PREFIX from CFG_{DATADIR,MANDIR,INFODIR,LIBDIR}

While these variables are not yet used by the Makefile, to be used
CFG_PREFIX must be stripped from them. The 'make install' rule creates
a tarball and then the install.sh script extracts it relative to the
prefix argument --prefix, which in the case of a Cargo install is
relative to CFG_PREFIX. This is why CFG_PREFIX needs to be stripped out
of CFG_DATADIR, CFG_MANDIR, CFG_INFODIR, and CFG_LIBDIR.

Signed-off-by: Doug Goldstein <cardoe@cardoe.com>

Auto merge of #2810 - munyari:jobs, r=alexcrichton

Update help for build to show number of jobs (#2805)

This addresses #2805

make jobs description fit inside 80 columns

Add color support for Windows consoles.

Fixes #2803

Auto merge of #2812 - rust-lang:package-in-cargo-toml, r=alexcrichton

Change cargo.toml to use `[package]`

These are aliases, but `[project]` is considered incorrect these days.

Change cargo.toml to use `[package]`

These are aliases, but `[project]` is considered incorrect these days.

Update help for build to show number of jobs (#2805)

Auto merge of #2795 - alexcrichton:test-and-harness, r=brson

Fix `harness = false` on `[lib]` sections

Now that this is fixed upstream, we can actually add a test for this!

Closes #2305

Fix `harness = false` on `[lib]` sections

Now that this is fixed upstream, we can actually add a test for this!

Closes #2305

Add support for RUSTDOCFLAGS

Like with RUSTFLAGS, parse this variable to pass along extra arguments to
invocations of `rustdoc`.

Auto merge of #2793 - matklad:doc-fix, r=alexcrichton

Fix reference to the guide in the docs

Overrides description was moved from the Guide to the Specifying
Dependencies section.

It would be nice to provide a hyperlink here, but I guess it is not possible.

Fix reference to the guide in the docs

Overrides description was moved from the Guide to the Specifying
Dependencies section.

Auto merge of #2788 - Manishearth:improve-help, r=alexcrichton

Clarify where full list of subcommands can be found

None

Clarify where full list of subcommands can be found

Auto merge of #2787 - alexcrichton:links-with-dots, r=brson

Don't re-look-up tables to avoid dots problem

If a `links` value has a `.` in the name Cargo would previously panic, but this
alters the code to be more principled about lookup in tables to ensure that we
don't misinterpret the names.

Closes #2786

Don't re-look-up tables to avoid dots problem

If a `links` value has a `.` in the name Cargo would previously panic, but this
alters the code to be more principled about lookup in tables to ensure that we
don't misinterpret the names.

Closes #2786

Auto merge of #2630 - alexcrichton:build-script-warnings, r=brson

Add build script warnings, streaming output from build scripts to the console

These commits add a few features to Cargo:

* Cargo now recognizes the `warning` key in build scripts and will print warnings *after a build script has completed* if the build script is for a path dependency. That is, if a build script prints `cargo:warning=foo` then Cargo will forward that to the console if the crate's being developed.

* Cargo now accepts multiple `-v` flags for all commands. The `-vv` flag prints warnings for *all* upstream crates, not just the local ones.

* When the `-vv` flag is passed Cargo will stream the output of all build scripts to the console, allowing more easy debugging of what happened if the build fails later on.

More details can be found in each commit, and otherwise this

Closes #1106

Stream build script output to the console

This commit alters Cargo's behavior when the `-vv` option is passed (two verbose
flags) to stream output of all build scripts to the console. Cargo makes not
attempt to prevent interleaving or indicate *which* build script is producing
output, rather it simply forwards all output to one to the console.

Cargo still acts as a middle-man, capturing the output, to parse build script
output and interpret the results. The parsing is still deferred to completion
but the stream output happens while the build script is running.

On Unix this is implemented via `select` and on Windows this is implemented via
IOCP.

Closes #1106

Allow specifying -v multiple times

This commit modifies the CLI interface to allow the verbose (-v) flag to be
specified multiple times. This'll be used soon to have `-vv` indicate that more
output should be generated than `-v` during a normal build.

Currently this commit changes the behavior of whether warnings are printed to
print warnings for the **entire DAG of dependencies** if `-vv` is specified.
That is, `--cap-lints` is never passed nor is any warning from build scripts if
`-vv` is specified.

Forward warnings from build scripts

This adds support for forwarding warnings from build scripts to the main console
for diagnosis. A new `warning` metadata key is recognized by Cargo and is
printed after a build script has finished executing.

The purpose of this key is for build dependencies to try to produce useful
warnings for local crates being developed. For example a parser generator could
emit warnings about ambiguous grammars or the gcc crate could print warnings
about the C/C++ code that's compiled.

Warnings are only emitted for path dependencies by default (like lints) so
warnings printed in crates.io crates are suppressed.

cc #1106

Auto merge of #2720 - alexcrichton:ignore-nfs-more-often, r=brson

Ignore file locks on OSX NFS mounts

We already ignore NFS on Linux so let's do the same on OSX as well.

Ignore file locks on OSX NFS mounts

We already ignore NFS on Linux so let's do the same on OSX as well.

Auto merge of #2741 - alexcrichton:cdylib, r=brson

Add support for cdylib crate types

And while we're at it this also extends support for all future crate types
assuming that they aren't linkable by default.

Auto merge of #2680 - alexcrichton:update-toml, r=brson

Update TOML parser to pick up a bugfix

Cargo has previously accepted invalid TOML as valid, but this bugfix should fix
the problem. In order to prevent breaking all crates immediately toml-rs has a
compatibility mode which emulates the bug that was fixed. Cargo will issue a
warning if this compatibility is required to parse a crate.

Auto merge of #2668 - alexcrichton:dont-warn-about-metadata, r=brson

Don't warn about `metadata` keys in the manifest

External tools may want to store metadata in `Cargo.toml` that they read but
Cargo itself doesn't read. For example `cargo-apk` uses this for pieces of
configuration. Cargo unfortunately, however, warns about these keys as "unused
keys in the manifest"

This commit instead whitelists the `package.metadata` key to not warn about any
data inside.

Update TOML parser to pick up a bugfix

Cargo has previously accepted invalid TOML as valid, but this bugfix should fix
the problem. In order to prevent breaking all crates immediately toml-rs has a
compatibility mode which emulates the bug that was fixed. Cargo will issue a
warning if this compatibility is required to parse a crate.

Don't warn about `metadata` keys in the manifest

External tools may want to store metadata in `Cargo.toml` that they read but
Cargo itself doesn't read. For example `cargo-apk` uses this for pieces of
configuration. Cargo unfortunately, however, warns about these keys as "unused
keys in the manifest"

This commit instead whitelists the `package.metadata` key to not warn about any
data inside.

Add support for cdylib crate types

And while we're at it this also extends support for all future crate types
assuming that they aren't linkable by default.

Auto merge of #2781 - alexcrichton:block-if-dirty, r=brson

Prevent packaging a crate if any files are dirty

This commit alters Cargo's behavior to prevent publishing a crate by default if
any files in that crate are determined to be dirty, that is either modified or
not part of the working tree.

This can prevent common mistakes like many listed in #2063 and enables features like https://github.com/rust-lang/cargo/issues/841.

Closes https://github.com/rust-lang/cargo/issues/1597
Closes #2063

Auto merge of #2757 - alexcrichton:panic-profile-dox, r=brson

Document the `panic` profile option

Closes #2750

Auto merge of #2704 - alexcrichton:clean-no-fetch, r=brson

Don't fetch all crates on clean

Only fetch those that are needed by avoiding `ops::fetch`

Auto merge of #2779 - matklad:propagete-color-config, r=alexcrichton

Propagate --color option to rustc

closes #2740

Will try to add a test for this soon (and fix failing tests if any, compiling/running tests locally is slow :( ).

I am not sure what is the right place to add `--color` option to the command line. I use [`build_base_args`]. [`process`] also looks like a good candidate, because it is more general, but if we look at the [`CommandType`] we see that only `rustc` command supports `--color`.

[`build_base_args`]: https://github.com/matklad/cargo/blob/1f7504397ce7c40ff708e2d31da164822e88ed37/src/cargo/ops/cargo_rustc/mod.rs#L449
[`process`]: https://github.com/matklad/cargo/blob/1f7504397ce7c40ff708e2d31da164822e88ed37/src/cargo/ops/cargo_rustc/mod.rs#L608
[`CommandType`]: https://github.com/matklad/cargo/blob/1f7504397ce7c40ff708e2d31da164822e88ed37/src/cargo/ops/cargo_rustc/engine.rs#L102

Prevent packaging a crate if any files are dirty

This commit alters Cargo's behavior to prevent publishing a crate by default if
any files in that crate are determined to be dirty, that is either modified or
not part of the working tree.

This can prevent common mistakes like many listed in #2063, and subsequently...

Closes #2063

Auto merge of #2780 - Boddlnagg:patch-1, r=alexcrichton

Fix `cargo doc --open` on Windows

This fixes #2446. Note that I have not built cargo with this change, but I have tested the functionality in isolation (on Windows 10).

As to the issue itself, I don't know why the previous version didn't work, but `start` is redundant when `cmd /C` is used.

Fix `cargo doc --open` on Windows

This fixes #2446. Note that I have not built cargo with this change, but I have tested the functionality in isolation (on Windows 10).

As to the issue itself, I don't know why the previous version didn't work, but `start` is redundant when `cmd /C` is used.

Propagate --color option to rustc

Auto merge of #2778 - alexcrichton:dont-print-on-q-when-run, r=brson

Don't print extra info on -q + `cargo run`

If a process fails then it's probably printing out why and Cargo doesn't need to
do it all over again.

Closes #2735

Don't print extra info on -q + `cargo run`

If a process fails then it's probably printing out why and Cargo doesn't need to
do it all over again.

Closes #2735

Auto merge of #2777 - matklad:harness-help, r=alexcrichton

Explain how to get help for the test harness

TIL that the default test harness has a non-trivial number of options. Guess it's better to share this knowledge.

Explain how to get help for the test harness

Auto merge of #2771 - alexcrichton:update-replace, r=brson

Don't lock overrides if we're updating them

There was already a function for this, `keep`, it was just forgotten to be
called.

Closes #2766

Auto merge of #2770 - alexcrichton:new-curl, r=brson

Update to curl 0.3

Auto merge of #2763 - mbrubeck:native-dirs, r=alexcrichton

Correctly record multiple native dirs per package

This fixes a bug when a package's build script outputs multiple library search
paths.  Because Compilation::native_dirs is a `HashMap<PackageId, PathBuf>` it
can only store one path per package.  Currently if there are multiple paths,
all but the last will be inserted and then overwritten.

The key from this map is never used anyway, so this fixes the bug by changing
it from a HashMap to a HashSet.

Test for correct library search paths during cargo run

Strip native= prefix from -L arg before additing it to LD_LIBRARY_PATH

Fixes #2765.

Correctly record multiple native dirs per package

This fixes a bug when a package's build script outputs multiple library search
paths.  Because Compilation::native_dirs is a `HashMap<PackageId, PathBuf>` it
can only store one path per package.  Currently if there are multiple paths,
all but the last will be inserted and then overwritten.

The key from this map is never used anyway, so this fixes the bug by changing
it from a HashMap to a HashSet.

Auto merge of #2774 - andrehjr:patch-doc-2754, r=alexcrichton

Document file destination of build scripts.

Close #2754

Document file destination of build scripts.

Close #2754

Auto merge of #2772 - knight42:patch, r=alexcrichton

Improve autocompletion

1. Add path completion to manifest-path options
2. Support subcommand metadata

Add zsh autocompletion to subcommand metadata