Auto merge of #5473 - ehuss:autobin-warning, r=alexcrichton

Address autobins warning.

Removes the large warning displayed if you build Cargo with itself (but adds a warning if you build with an older Cargo).  Not sure which approach you prefer to address it, or if you want to do this later.

Address autobins warning.

Auto merge of #5470 - alexcrichton:hopeful-fix, r=matklad

Attmept to fix a spurious failure on AppVeyor

I *think* the issue is that `link.exe` is generating debuginfo in the background
which keeps the file open and prevents us from deleting it, but hopefully by
disabling debug information we'll either be able to confirm or deny this
hypothesis.

Attmept to fix a spurious failure on AppVeyor

I *think* the issue is that `link.exe` is generating debuginfo in the background
which keeps the file open and prevents us from deleting it, but hopefully by
disabling debug information we'll either be able to confirm or deny this
hypothesis.

Auto merge of #5468 - matklad:aliases, r=alexcrichton

Tweak handling of aliases

Previously, `execute_subcommand` was called recursively, and each call
would `.configure` the `config` again. It worked, but seemed rather
fragile.

This commit handles aliases more explicitly, ensures that `.configure`
is called once and, as a bonus, adds a warning for when an alias is
shadowed by the built in.

Tweak error messages

By convention, all errors should start with a lowercase letter

Make alias handling more straightforward

Previously, `execute_subcommand` was called recursively, and each call
would `.configure` the `config` again. It worked, but seemed rather
fragile.

This commit handles aliases more explicitly, ensures that `.configure`
is called once and, as a bonus, adds a warning for when an alias is
shadowed by the built in.

Auto merge of #5464 - ehuss:restore-example-test, r=alexcrichton

Partially revert change to testing examples.

Fixes #5437

I don't think changing the behavior was quite the correct thing to do.  This new behavior is very similar to the old with a few small differences:

```
cargo test
    ORGINAL: Only builds examples.
    NEW: Builds all examples.  Any example with `test` set is tested.

cargo test --tests
    ORIGINAL: Runs all examples as tests.
    NEW: Only runs examples as tests if `test` is set.

cargo test --examples
    ORIGINAL: Runs all examples as tests.
    NEW: (SAME)

cargo test --example foo
    ORIGINAL: Runs the given example as a test.
    NEW: (SAME)

cargo test --all-targets
    ORIGINAL: Runs all examples as tests.
    NEW: (SAME)
```

Auto merge of #5469 - matklad:fix-link, r=matklad

Fix link in docs

Fix link in docs

Auto merge of #5466 - matklad:pr-5465, r=matklad

Fix target_dir handling for RLS

Supersedes  and closes #5465

Fix the test

Revert part to #5393

Commit 0b530c30867da26a4b59146f490c9f1d5377c20a (which this commit mostly reverts) did some refactoring around the `target_dir` function. However, it introduced a bug because it meant that where `CARGO_TARGET_DIR` was specified but `--target-dir` was not, the value from `CARGO_TARGET_DIR` was ignored.

Partially revert change to testing examples.

Fixes #5437

I don't think changing the behavior was quite the correct thing to do.  This new behavior is very similar to the old with a few small differences:

```
cargo test
    ORGINAL: Only builds examples.
    NEW: Builds all examples.  Any example with `test` set is tested.

cargo test --tests
    ORIGINAL: Runs all examples as tests.
    NEW: Only runs examples as tests if `test` is set.

cargo test --examples
    ORIGINAL: Runs all examples as tests.
    NEW: (SAME)

cargo test --example foo
    ORIGINAL: Runs the given example as a test.
    NEW: (SAME)

cargo test --all-targets
    ORIGINAL: Runs all examples as tests.
    NEW: (SAME)
```

Auto merge of #5462 - matklad:install-releases, r=alexcrichton

Don't install pre-releases by default

Currently, `cargo install` will try to install a pre-release version, if available (try `cargo install rand`). This happens because we use `VersionReq::any`, if no version is specified, and that matches pre-releases. The fix is to use `*`, which is different from `any`.

This needs to be done in `cargo install`, and not directly in `parse_no_deprecated`, the latter would be wrong, as demonstrated by a new test with patch.

Don't install pre-releases by default

Auto merge of #5459 - matklad:more-comments, r=alexcrichton

Explain why we need a `Vec<Dependency>` in `Resolve`.

Looks like everyone, who sees it, asks the same question, so let's add an explanation!

cc https://github.com/rust-lang/cargo/pull/5428#issuecomment-385459845

Auto merge of #5456 - LukasKalbertodt:patch-1, r=matklad

Show elapsed time in minutes if >= 60 secs

In large projects with long compile times, seeing "428.65 secs" isn't as clear to humans as seeing the number of minutes (and seconds).

**Old**:
```
Finished dev [unoptimized + debuginfo] target(s) in 2.23 secs
Finished dev [unoptimized + debuginfo] target(s) in 63.94 secs
Finished dev [unoptimized + debuginfo] target(s) in 428.65 secs
```

**New**:
```
Finished dev [unoptimized + debuginfo] target(s) in 2.23s
Finished dev [unoptimized + debuginfo] target(s) in 1m 3.94s
Finished dev [unoptimized + debuginfo] target(s) in 7m 8.65s
```

Note that I also changed `secs` to `s`, because `7 mins 8.65 secs` and `7m 8.65 secs` both look strange IMO. But if you disagree and you'd prefer `secs`, just tell me and I'll change it.

I *didn't* add a check for `secs >= 3600` to print the time in hours. I *hope* this is not necessary...

Auto merge of #5458 - alexcrichton:track-panic, r=matklad

Track panic mode in fingerprint

Ensure that if we've previously compiled a crate with panic=abort and we later
need it for panic=unwind we correctly recompile it.

Closes #5445

Adjust tests to new time output format

Show elapsed time in minutes if >= 60 secs

In large projects with long compile times, seeing "400.65 secs" isn't as
clear as seeing the number of minutes (and seconds).

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

Fix optional dependencies and required dev-deps

This fixes an accidental bug introduced in #5300 by ensuring a local map keeps
track of the fact that there can be multiple dependencies for one name

Closes #5453

Explain why we need a `Vec<Dependency>` in `Resolve`.

Auto merge of #5446 - csmoe:new_name, r=alexcrichton

Emit correct project name with --name

Fixes #5440

Track panic mode in fingerprint

Ensure that if we've previously compiled a crate with panic=abort and we later
need it for panic=unwind we correctly recompile it.

Closes #5445

Auto merge of #5432 - djc:split-context, r=alexcrichton

Split Context into two types

@matklad here's the crazy attempt to make the `Context` situation slightly more sane. It basically splits all of the stuff that is immutable over the lifetime of the compilation from the stuff that's initialized empty. The latter is now stored in a type which I have provisionally called `BuildProgress` -- feel free to bikeshed about the name (I came up with `BuildData` as another alternative). It stores a reference to the `Context` to make things easier for now, we might want to change that down the line.

IMO this is a pretty good improvement, which clarifies the design quite a bit.

@alexcrichton you'll probably want to review this, too.

Store unit dependencies directly into Context

Move Links into context module

Extract new build_context module out of context module

Split Context into two types

Fix optional dependencies and required dev-deps

This fixes an accidental bug introduced in #5300 by ensuring a local map keeps
track of the fact that there can be multiple dependencies for one name

Closes #5453

Auto merge of #5451 - DarkDrek:add_doc_clean, r=alexcrichton

Add cargo clean --doc

Implements #5449.
It only removes the doc directory and therefore keeps all other build artifacts intact.
When `--doc` is used all other options are ignored.

My test case is mostly copy&paste from `clean_release` so maybe the `.toml`s can be simplified.

Add cargo clean --doc

Let Context store BuildConfig by reference

Auto merge of #5447 - ehuss:ws-error-message, r=alexcrichton

Better error message for `cargo rustc` in a workspace.

Fixes #5371

Auto merge of #5448 - ehuss:debug_env, r=alexcrichton

Fix "DEBUG" env var in build.rs for debug=0

Fixes #5370

Better error message for `cargo rustc` in a workspace.

Fixes #5371

add test for project name

fix project name

Auto merge of #5443 - rtsuk:update-doc-env-var, r=alexcrichton

Update documentation on config via environment variables

Use source replacement as a specific example of the kind
of configuration feature that cannot currently be set by
environmental variables.

Auto merge of #5300 - djc:namespaced-features, r=alexcrichton

Introduction of namespaced features (see #1286)

I think this basically covers all of the plans from #1286, although it still needs a bunch of tests and documentation updates. Submitting this PR to get some early feedback on the direction.

Fix "DEBUG" env var in build.rs for debug=0.

Fixes #5370

Update documentation on config via environment variables

Use source replacement as a specific example of the kind
of configuration feature that cannot currently be set by
environmental variables.

Put namespaced features behind a feature gate

Auto merge of #5430 - matklad:bring-old-features-back, r=alexcrichton

Revert "Enable new behavior of `--feature`"

This reverts commit 038eec5cb3bd25a0855b0be6ad2aeba5391c6c6e.

As discussed at https://github.com/rust-lang/cargo/issues/5364, the new behavior unfortunately causes real-life breakage, so we have to revert it.

This is kinda sad, this is a part of the larger issue with feature selection, which, at the moment, has a behavior which I would classify (loosely speaking) as unsound:

* `cargo build -p foo` and `cargo build -p foo -p bar` might produce different artifacts for `foo` ([repro](https://github.com/matklad/workspace-vs-feaures))
* `cargo build -p foo` might produce different artifacts, depending on cwd ([repro](https://github.com/matklad/features-cwd))

The new feature behavior specifically addressed the second point.

It is unclear what we could do with this... One option, instead of flatly erroring out, as the revreted commit does, is to print a warning, but change the set of activated features. It will still be a breaking change, but it at least has  a chance of working by accident.

r? @alexcrichton

Auto merge of #5425 - matklad:rename-fingerprint, r=alexcrichton

Package renames should affect fingerprints

Auto merge of #5428 - matklad:graph-with-edges, r=alexcrichton

Store dependencies as edges of the graph

r? @alexcrichton

Auto merge of #5429 - matklad:dashes-test, r=matklad

Extend dashes forwarding test

Closes https://github.com/rust-lang/cargo/issues/2213

Looks like this was fixed when we've transitioned to clap!

Extend dashes forwarding test

Revert "Enable new behavior of `--feature`"

This reverts commit 038eec5cb3bd25a0855b0be6ad2aeba5391c6c6e.

Store dependencies as edges of the graph

Add some documentation about unstable namespaced-features feature

Add tests for namespaced features

Take feature namespace into account while building summary (fixes #1286)

Here's an attempt at a table to cover the different cases:

Feature
    Old (must be in features table)
        Continue
    Namespaced (might be stray value)
        In features table: Check that Crate dependency is in the list
        -> Non-optional dependency: Bail [PREVIOUSLY: bailed for non-optional dependency]
        -> Optional dependency: Insert feature of this name
        -> Else: Bail [PREVIOUSLY: bailed for unknown dependency or feature]

Crate
    Old (might be stray value)
        Non-optional dependency: Bail
        No dependency found: Bail
    Namespaced
        Non-optional dependency: Bail
        No dependency found: Bail

CrateFeature
    Old
        No dependency found: Bail
    Namespaced
        No dependency found: Bail

Keep track of namespaced-features flag in Summary objects

For now, all Summaries from a registry have it set to false.

Add namespaced-features option for manifest [project] section

Make a dependencies map while building feature map

Simplify retrieval of dependency data

Mix package renames into fingerprints

Auto merge of #5384 - ehuss:profile-override, r=matklad

Profile Overrides (RFC #2282 Part 1)

Profile Overrides (RFC #2282 Part 1)

WIP: Putting this up before I dig into writing tests, but should be mostly complete.  I also have a variety of questions below.

This implements the ability to override profiles for dependencies and build scripts.  This includes a general rework of how profiles work internally. Closes #5298.

Profile overrides are available with `profile-overrides` set in `cargo-features` in the manifest.

Part 2 is to implement profiles in config files (to be in a separate PR).

General overview of changes:

- `Profiles` moved to `core/profiles.rs`. All profile selection is centralized there.
- Removed Profile flags `test`, `doc`, `run_custom_build`, and `check`.
- Removed `Profile` from `Unit` and replaced it with two enums: `CompileMode` and `ProfileFor`.  This is the minimum information needed to compute profiles at a later stage.
- Also removed `rustc_args`/`rustdoc_args` from `Profile` and place them in `Context`.  This is currently not very elegant because it is a special case, but it works. An alternate solution I considered was to leave them in the `Profile` and add a special uber-override layer.  Let me know if you think it should change.
- Did some general cleanup in `generate_targets`.

## Misc Fixes
- `cargo check` now honors the `--release` flag.  Fixes #5218.
- `cargo build --test` will set `panic` correctly for dependences. Fixes #5369.
- `cargo check --tests` will no longer include bins twice (once as a normal check, once as a `--test` check).  It only does `--test` check now.
    - Similarly, `cargo check --test name` no longer implicitly checks bins.
- Examples are no longer considered a "test".  (See #5397). Consequences:
    - `cargo test` will continue to build examples as a regular build (no change).
    - `cargo test --tests` will no longer build examples at all.
    - `cargo test --all-targets` will no longer build examples as tests, but instead build them as a regular build (now matches `cargo test` behavior).
    - `cargo check --all-targets` will no longer check examples twice (once as
      normal, once as `--test`).  It now only checks it once as a normal
      target.

## Questions
- Thumbs up/down on the general approach?
- The method to detect if a package is a member of a workspace should probably be redone.  I'm uncertain of the best approach.  Maybe `Workspace.members` could be a set?
- `Hash` and `PartialEq` are implemented manually for `Profile` only to avoid matching on the `name` field.  The `name` field is only there for debug purposes. Is it worth it to keep `name`?  Maybe useful for future use (like #4140)?
- I'm unhappy with the `Finished` line summary that displays `[unoptimized + debuginfo]`.  It doesn't actually show what was compiled.  Currently it just picks the base "dev" or "release" profile.  I'm not sure what a good solution is (to be accurate it would need to potentially display a list of different options).  Is it ok?  (See also #4140 for the wrong profile name being printed.)
- Build-dependencies use different profiles based on whether or not `--release` flag is given.  This means that if you want build-dependencies to always use a specific set of settings, you have to specify both `[profile.dev.build_override]` and `[profile.release.build_override]`.  Is that reasonable (for now)?  I've noticed some issues (like #1774, #2234, #2424) discussing having more control over how build-dependencies are handled.
- `build --bench xxx` or `--benches` builds dependencies with dev profile, which may be surprising.  `--release` does the correct thing.  Perhaps print a warning when using `cargo build` that builds benchmark deps in dev mode?
- Should it warn/error if you have an override for a package that does not exist?
- Should it warn/error if you attempt to set `panic` on the `test` or `bench` profile?

## TODO
- I have a long list of tests to add.
- Address a few "TODO" comments left behind.

Minor style update.

Comment why `deps_of` doesn't need to keep track of `profile_for` in map.

Fix Unit/Context parameter order.

Avoid building libs and bins twice in `cargo build --all-targets --release`.

This changes it so that `Build` mode is not set in the Unit, since there is
no difference between Bench and Test once the profile has been selected.

Update tests now that `cargo check` does not re-check bins.

Add some more tests.

Add thorough tests for target/profile selection.

Move profile override tests to a dedicated file.

rustfmt

Remove last TODO comments.

Some test cleanup for profiles.

Add more profile override validation tests.

Add test for profile override on non-dev/release.

Add warning if `panic` is set in test or bench profile.

Add warnings for unknown profile overrides.

Minor tweaks on how examples are handled with tests, and some panic propagation.

Avoid running `build.rs` too often.

Add extra rustc/rustdoc args to the fingerprint and metadata.

Update for some review comments.

Fix a variety of profile bugs.

Move `Profile` back into `Unit` as a copy.

The de-duplication of Units just doesn't work without it.

Minor cleanup.

Profile Overrides (RFC #2282 Part 1)

Auto merge of #5415 - alexcrichton:rename-same-dep, r=matklad

Fix renaming crates as they come from 2 sources

Previously there was a verification in manifest parsing that the same dependency
must come from the same source, but this erroneously triggered an error to get
emitted when the `package` key was used to rename crates. The first change here
was to update that clause to key off the `rename` field rather than the `name`
field.

Afterwards, though, this exposed an existing bug in the implementation. During
compilation we have a `Resolve` which is a graph of crates, but we don't know
*why* each edge in the dependency graph exists. In other words we don't know,
when looking at an edge of the graph, what `Dependency` caused that edge to be
drawn. We need to know this when passing `--extern` flags because the
`Dependency` is what lists what's being renamed.

This commit then primarily refactors `Resolve::deps` from an iterator of package
ids to an iterator of a tuples. The first element is the package id from before
and the second element is a list of `Dependency` directives which caused the
edge to ber driven.

This refactoring cleaned up a few places in the backend where we had to work
around the lack of this knowledge. Namely this also fixes the extra test added
here.

Closes #5413

Fix renaming crates as they come from 2 sources

Previously there was a verification in manifest parsing that the same dependency
must come from the same source, but this erroneously triggered an error to get
emitted when the `package` key was used to rename crates. The first change here
was to update that clause to key off the `rename` field rather than the `name`
field.

Afterwards, though, this exposed an existing bug in the implementation. During
compilation we have a `Resolve` which is a graph of crates, but we don't know
*why* each edge in the dependency graph exists. In other words we don't know,
when looking at an edge of the graph, what `Dependency` caused that edge to be
drawn. We need to know this when passing `--extern` flags because the
`Dependency` is what lists what's being renamed.

This commit then primarily refactors `Resolve::deps` from an iterator of package
ids to an iterator of a tuples. The first element is the package id from before
and the second element is a list of `Dependency` directives which caused the
edge to ber driven.

This refactoring cleaned up a few places in the backend where we had to work
around the lack of this knowledge. Namely this also fixes the extra test added
here.

Closes #5413

Auto merge of #5349 - bmwill:fetch-by-target, r=alexcrichton

cargo-fetch: add option to fetch for a target

Teach cargo-fetch how to optionally fetch dependencies based on a target
platform by specifying the target triple via `--target <TRIPLE>`.

#5216

Auto merge of #5410 - klnusbaum:edition_5406, r=matklad

switch to using the --edition flag

Now that we have an `--edition` flag in the rust compiler, let's switch to using it.

fixes #5406

cargo-fetch: add option to fetch for a target

Teach cargo-fetch how to optionally fetch dependencies based on a target
platform by specifying the target triple via `--target <TRIPLE>`.

Signed-off-by: Brandon Williams <bmwill@google.com>

Auto merge of #5394 - henriklaxhuber:master, r=alexcrichton

Pass linker path to build script

This change adds the environment variable LINKER to pass the path of the linker used by cargo to the build script. This complements the variable RUSTC (the rustc binary used) to give the build script full knowledge of its environment.

A specific usage example would be automatically generating bindings to system headers in cross compilation, e.g. by locating jni.h for android targets.

Auto merge of #5393 - smithsps:master, r=matklad

Add target directory parameter --target-dir

Implements: https://github.com/rust-lang/cargo/issues/5308

Adds a target directory parameter, that acts in the same manner as the environment variable `CARGO_TARGET_DIR`, to the following subcommands:
- `bench`
- `build`
- `check`
- `clean`
- `doc`
- `package`
- `publish`
- `run`
- `rustc`
- `rustdoc`
- `test`

Auto merge of #5398 - dwijnand:drop-legacy-paths, r=matklad

Drop legacy path support under Rust edition 2018 (or later)

builds on #5335

submitted for early feedback: wdyt @matklad? is this what you had in mind? what should change? what should be added? how should we test this? is the current (2015) messaging enough to drop it in 2018?

r? @matklad

<!--{"baseBranch":"rust-lang:cargo:target-autodiscovery"}-->

Add target directory parameter: address suggestions

Moved RUSTC_LINKER test into its own fn

Add target directory parameter --target-dir

Fixed RUSTC_LINKER test for Windows hosts

Fixed build script env var test

Added tests for RUSTC_LINKER buils script env var

Added tests for the environment variable RUSTC_LINKER that is
passed to the build script.
Also slightly improved readability of the code responsible for
passing the env var.

switch to using the --edition flag

Auto merge of #5407 - klausi:fixed-minimal-versions, r=matklad

fix(dependendies): Bump minimal dependency versions so that cargo successfully builds with those

Spin-off from #5275 .

Just bump the minimum dependency versions here, we are developing CI testing in #5275 .

fix(dependendies): Bump minimal dependency versions so that cargo successfully builds with those