Fix the edition build scripts are compiled with

Previously build scripts were accidentally and unconditionally compiled with the
2015 edition, but they should instead use the edition of the `[package]` itself.

Closes #5860

Auto merge of #5845 - alexcrichton:fix-edition, r=alexcrichton

Rename `--prepare-for` to `--edition`, drop arg

This commit tweaks the UI of `cargo fix` for the edition. Previously you'd
execute `cargo fix --prepare-for 2018`, but that's a lot of typing! Plus it's
some manual data that Cargo can already infer.

Instead, after this commit, you now type `cargo fix --edition`, and that's it!
The idea is that this'll tell Cargo to fix code for the *next* edition,
inferring whatever edition is in use and figuring out what to pass to rustc.

Functionality-wise this should be the exact same as `--prepare-for 2018` though

If others agree w/ this change I'll send a PR to the edition guide after this
merges!

Auto merge of #5851 - dwijnand:slash-macro, r=alexcrichton

Drop the [/] test output macro

Refs #5742

Push slash conforming to lines_match, so match_json uses it

Drop the [/] test output macro

Switch strategies for how rustc's workspace is unioned

See rust-lang/rust#52919 for more details.

Rename `--prepare-for` to `--edition`, drop arg

This commit tweaks the UI of `cargo fix` for the edition. Previously you'd
execute `cargo fix --prepare-for 2018`, but that's a lot of typing! Plus it's
some manual data that Cargo can already infer.

Instead, after this commit, you now type `cargo fix --edition`, and that's it!
The idea is that this'll tell Cargo to fix code for the *next* edition,
inferring whatever edition is in use and figuring out what to pass to rustc.

Functionality-wise this should be the exact same as `--prepare-for 2018` though

If others agree w/ this change I'll send a PR to the edition guide after this
merges!

Auto merge of #5831 - Eh2406:i5684, r=alexcrichton

cargo can silently fix some bad lockfiles (use --locked to disable)

Lock files often get corrupted by git merge. This makes all cargo commands silently fix that kind of corruption.

If you want to be sure that your CI does not change the lock file you have commited
---

Then make sure to use `--locked` in your CI

Edit: original description below

---------------

This is a continuation of @dwijnand work in #5809, and closes #5684

This adds a `ignore_errors` arg to reading a lock file which ignores sections it doesn't understand. Specifically things that depend on versions that don't exist in the lock file. Then all users pass false except for the two that relate to `update` command.

I think the open questions for this pr relate to testing.
- Now that we are passing false in all other commands, do they each need a test for a bad lockfile?
- Do we need a test with a more subtly corrupted lock file, or is this always sufficient for `update` to clean up?

Auto merge of #5834 - Undin:metadata-edition, r=alexcrichton

Add edition info into metadata

Since edition feature was introduced, external tools have to support this new feature.
But cargo metadata doesn't provide info about package edition.
This commit adds edition field to `SerializedPackage` struct to add the corresponding field into metadata output.

Auto merge of #5847 - alexcrichton:fix-deprecations, r=alexcrichton

Upgrade to `failure 0.1.2` idioms

Fixes some deprecation warnings in Cargo

Upgrade to `failure 0.1.2` idioms

Fixes some deprecation warnings in Cargo

fix tests on Windows

Auto merge of #5842 - alexcrichton:fix-lots, r=ehuss

fix: Iteratively apply suggestions from the compiler

This commit updates the `cargo fix` implementation to iteratively apply fixes
from the compiler instead of only once. Currently the compiler can sometimes
emit overlapping suggestions, such as in the case of transitioning

    ::foo::<::Bar>();

to ...

    crate::foo::<crate::Bar>();

and `rustfix` rightfully can't handle overlapping suggestions as there's no
clear way of how to disambiguate the fixes. To fix this problem Cargo will now
run `rustc` and `rustfix` multiple times, attempting to reach a steady state
where no fixes failed to apply.

Naturally this is a pretty tricky thing to do and we want to be sure that Cargo
doesn't loop forever, for example. A number of safeguards are in place to
prevent Cargo from going off into the weeds when fixing files, notably avoiding
to reattempt fixes if no successful fixes ended up being applied.

Closes #5813
Closes rust-lang/rust#52754

Auto merge of #5841 - Mark-Simulacrum:internal-error-json, r=alexcrichton

Consider rustc failure internal despite JSON formatting

@eddyb noted this on IRC I believe, this should make compiler devs in general happy in 6 weeks once this lands onto beta

r? @alexcrichton

Auto merge of #5840 - ehuss:uninstall-spec, r=alexcrichton

Allow `-p` in `uninstall` to accommodate error messages.

The ambiguous spec error tells you to use `-p` which wasn't available for
this command.

Fixes #5006

Add edition field into target object in metadata as well

Auto merge of #5836 - kornelski:profiledebug, r=alexcrichton

Hint correct name of profile.debug

Cargo talks about "debug" and "release" builds, but there are "dev" and "release" profiles. [This is a gotcha](https://users.rust-lang.org/t/rust-emscripten-emterpreter/19215/5). I've added an explicit hint that `profile.debug` is supposed to be `profile.dev`.

fix: Iteratively apply suggestions from the compiler

This commit updates the `cargo fix` implementation to iteratively apply fixes
from the compiler instead of only once. Currently the compiler can sometimes
emit overlapping suggestions, such as in the case of transitioning

    ::foo::<::Bar>();

to ...

    crate::foo::<crate::Bar>();

and `rustfix` rightfully can't handle overlapping suggestions as there's no
clear way of how to disambiguate the fixes. To fix this problem Cargo will now
run `rustc` and `rustfix` multiple times, attempting to reach a steady state
where no fixes failed to apply.

Naturally this is a pretty tricky thing to do and we want to be sure that Cargo
doesn't loop forever, for example. A number of safeguards are in place to
prevent Cargo from going off into the weeds when fixing files, notably avoiding
to reattempt fixes if no successful fixes ended up being applied.

Closes #5813
Closes rust-lang/rust#52754

Auto merge of #5835 - dwijnand:clippy, r=alexcrichton

Resolve some Clippy warnings

I'm not sure how these popped up since my PR 8 days ago.

My current hypotheses:
* changes in latest nightly rust/clippy
* new or changed cargo code
* I missed these as I was only touching `src/bin/cargo/main.rs`

For future reference I now iterate with:

    touch src/bin/cargo/main.rs src/cargo/lib.rs && cargo +nightly clippy

Move all clippy config to target top files

Add edition field into metadata.

Since edition feature was introduced, external tools have to support this new feature.
But cargo metadata doesn't provide info about package edition.
This commit adds edition field to SerializedPackage struct
to add the corresponding field into metadata output.

Auto merge of #5824 - alexcrichton:careful-transition, r=alexcrichton

Add more diagnostics to smooth edition transition

This commit adds two diagnostics in particular to ease the transition into the
2018 edition. The current transition process is pretty particular and must be
done carefully, so let's try to automate things to make it as painless as
possible! Notably the new diagnostics are:

* If you `cargo fix --prepare-for 2018` a crate which already has the 2018
  edition enabled, then an error is generated. This is because the compiler
  can't prepare for the 2018 edition if you're already in the 2018 edition, the
  lints won't have a chance to fire. You can only execute `--prepare-for 2018`
  over crates in the 2015 edition.

* If you `cargo fix --prepare-for 2018` and have forgotten the
  `rust_2018_preview` feature, a warning is issued. The lints don't fire unless
  the feature is enabled, so this is intended to warn in this situation to
  ensure that lints fire as much as they can.

After this commit if `cargo fix --prepare-for` exits successfully with zero
warnings then crates should be guaranteed to be compatible!

Closes #5778

Consider rustc failure internal despite JSON formatting

remove `missing from the package list` error and fmt

Allow `-p` in `uninstall` to accommodate error messages.

The ambiguous spec error tells you to use `-p` which wasn't available for
this command.

Fixes #5006

Auto merge of #5811 - alexcrichton:rename-crate-feature-names, r=ehuss

Use listed dependency name for feature names

This commit updates the implementation of renamed dependencies to use the listed
name of a dependency in Cargo.toml for the name of the associated feature,
rather than using the package name. This'll allow disambiguating between
different packages of the same name and was the intention all along!

Closes #5753

Auto merge of #5816 - dwijnand:edtion-per-target, r=alexcrichton

Edition key should be per-target, not per-package

Fixes #5661

I've pushed this WIP PR as I'd love some early feedback on it and some tips on:

* how to best to make it fail if edition is set on a target, but the feature isn't set; and
* what tests this should include (i.e how exhaustive should I go)

Thanks!

Use listed dependency name for feature names

This commit updates the implementation of renamed dependencies to use the listed
name of a dependency in Cargo.toml for the name of the associated feature,
rather than using the package name. This'll allow disambiguating between
different packages of the same name and was the intention all along!

Closes #5753

Add more diagnostics to smooth edition transition

This commit adds two diagnostics in particular to ease the transition into the
2018 edition. The current transition process is pretty particular and must be
done carefully, so let's try to automate things to make it as painless as
possible! Notably the new diagnostics are:

* If you `cargo fix --prepare-for 2018` a crate which already has the 2018
  edition enabled, then an error is generated. This is because the compiler
  can't prepare for the 2018 edition if you're already in the 2018 edition, the
  lints won't have a chance to fire. You can only execute `--prepare-for 2018`
  over crates in the 2015 edition.

* If you `cargo fix --prepare-for 2018` and have forgotten the
  `rust_2018_preview` feature, a warning is issued. The lints don't fire unless
  the feature is enabled, so this is intended to warn in this situation to
  ensure that lints fire as much as they can.

After this commit if `cargo fix --prepare-for` exits successfully with zero
warnings then crates should be guaranteed to be compatible!

Closes #5778

Resolve a single_match lint warning

Exempt 2 wrong_self_convention lint warnings

Resolve a trivially_copy_pass_by_ref lint warning

Resolve a wrong_self_convention lint warning

Resolve a wrong_self_convention lint warning

.. by inlining & removing `Members::is_empty`.

For details see
https://rust-lang-nursery.github.io/rust-clippy/v0.0.212/index.html#wrong_self_convention

Asides from opt-ing out, the alternative I saw was calling it
"into_empty" and make it return a little

    enum Empty { Empty, NonEmpty }

type.

Resolve 2 needless_pass_by_value lint warnings

TIL Rust doesn't have equational reasoning.. :-/
(can't inline the new "exec" bindings)

Add tests for per-target edition

Test:
* enabling edition feature & setting at target level (happy path)
* overriding the package-level edition with per-target edition
* feature gating of per-target edition
* per-target edition usage for rustdoc

Wire Features down to targets::configure to check the edition feature gate

Document per-target edition & give an example

Hint correct name of profile.debug

Exempt too_many_arguments throughout the cargo lib crate

I'm confused.  Now this is duplicated with src/bin/cargo/main.rs and I
don't know how to avoid that.  Tips welcome.

Exempt 3 identity_op lint warnings

fix: Only fix "primary" packages by default

The previous heuristic for fixing packages was to fix all packages in a
workspace, aka those with path dependencies. Instead this commit switches cargo
over to only fixing the "primary" package, or those requested on the command
line or implicitly via cwd.

This will later help us identify which packages are being targeted so we can
provide tailored warnings and errors for mixed up transition steps.

Auto merge of #5814 - alexcrichton:fix-all-targets, r=alexcrichton

cargo fix: Pass `--all-targets` to `cargo fix` by default

This'll help fix as much code as possible, including tests!

Closes #5739

use enum instead of bool

Auto merge of #5832 - Eh2406:collect_seq, r=alexcrichton

remove some allocations in Serialize

I have know reason to think this is in the hot path, but don't allocate if we don't have to.

remove some allocations in Serialize

cargo update can deal with some bad lockfiles

Auto merge of #5830 - Xanewok:executor-compile-mode, r=matklad

Add CompileMode to Executor callbacks

This came up when trying to fix https://github.com/rust-lang-nursery/rls/issues/876.

So currently in the RLS we recreate our own dep graph, where we store units with a key `(PackageId, TargetKind)`. This turned out to be not enough since
a) we can have multiple bin target kinds with different names (unrelated to this PR)
b) same package target kind (bin, lib) can be compiled regularly or including the test harness.
With this, we can distinguish these cases and properly rerun both regular compilation check and the one including unit tests.

Without this information we'd need to fall back on guessing whether the rustc invocation has `--test` but having this information makes it accurate and seems useful enough to add it to the callback arguments.

r? @alexcrichton or @matklad

Add CompileMode to Executor callbacks

This helps distinguish whether a given rustc invocation corresponds to a
regular compilation or is it compiled as a test harness. The difference is
important for tools like RLS, since checking test code is different than
checking what is it regularly compiled as.

Auto merge of #5828 - kennytm:compile-progress-names, r=alexcrichton

-Zcompile-progress: Use the target name in the progress bar when building a test/binary.

Thus fixes hilarious output like
https://twitter.com/ManishEarth/status/1015479576670027776.

New output: https://asciinema.org/a/F1rkCk0bTWKQMr1NEScia3IYx

Use the target name in the progress bar when building a test/binary.

Thus fixes hilarious output like
https://twitter.com/ManishEarth/status/1015479576670027776.

Default target edition to package edition

fix: Pass `--all-targets` to `cargo fix` by default

This'll help fix as much code as possible, including tests!

Closes #5739

Wire target edition to rustc/rustdoc

Wire Fingerprint to target unit's edition

Add an Edition on TomlTarget & Target, & wire

Auto merge of #5812 - dwijnand:move-existing_vcs_repo, r=alexcrichton

Move existing_vcs_repo to the util::vcs module

Rather than being in cargo_new publically exposed and used by cargo fix.

Just a proposal, as it looked weird to me.

Auto merge of #5810 - Eh2406:test-fix, r=alexcrichton

now that we respect gitignore tests can be simplified

There are a lot of test that used a tempfile to avoid the fact that cargo would not init a git in the test folder. (or because they were copy/pasted from one that did.) Now that #5733 landed we can remove them all.

Auto merge of #5807 - dwijnand:cargo-list-summary, r=alexcrichton

Show the command summary when running cargo --list

Fixes #3726

Auto merge of #5801 - ehuss:fix-doctestable, r=alexcrichton

Fix `test --doc` with incompatible lib types.

When I recently changed the doctest handling, I forgot to check the lib type in
the `test --doc` scenario.

I also added the package name to a nearby error message, since it can be
confusing in a workspace setting.

Move existing_vcs_repo to the util::vcs module

Rather than being in cargo_new publically exposed and used by cargo fix.

Avoid right-padding commands with spaces

Primarily because it needlessly breaks tests.

Adapt --list output in find_closest_biuld_to_build test

Auto merge of #5804 - dwijnand:hg-discover, r=alexcrichton

Fix HgRepo::discover

Replace the duplicate .cwd call with an invocation taken from
https://stackoverflow.com/a/3138925/463761

Match the semantics of the other vcs calls, which is invoke from 'cwd'
targeting 'path'. Looks a little confusing because hg takes a '--cwd'
argument.

remove all of the (now) unnecessary temp file usage in tests

update test for #5733

Auto merge of #5733 - withoutboats:cargo-new-respects-gitignore, r=alexcrichton

Respect .gitignore during `cargo new`

When running `cargo new`, we check to see if you are inside a git repository. If you are, we do not initialize a new git repo for your project unless you specifically asked for it using --vcs. (See #1210 for more background).

This commit changes that behavior to *also* create a new repo if the project would be an ignored path in the parent repository. This way, if your home directory is a git repository, as long as you have ignored the directory you are creating a new project in, we will instantiate a git repository without you having to specifically request it.

Auto merge of #5802 - ehuss:fix-doc-typo, r=dwijnand

Fix minor typo in the book.

Test verbose error output for a bad lockfile

Suggest "update -p" to fix a bad lockfile

Respect .gitignore during `cargo new`

When running `cargo new`, we check to see if you are inside a git
repository. If you are, we do not initialize a new git repo for
your project unless you specifically asked for it using --vcs.
(See #1210 for more background).

This commit changes that behavior to *also* create a new repo if
the project would be an ignored path in the parent repository.
This way, if your home directory is a git repository, as long as
you have ignored the directory you are creating a new project in,
we will instantiate a git repository without you having to
specifically request it.

Fix read-manifest summary printing under cargo --list

Show the command summary when running cargo --list

Reformat main::list_commands to return CommandInfo over a tuple

Fix HgRepo::discover

Replace the duplicate .cwd call with an invocation taken from
https://stackoverflow.com/a/3138925/463761

Match the semantics of the other vcs calls, which is invoke from 'cwd'
targeting 'path'. Looks a little confusing because hg takes a '--cwd'
argument.

Auto merge of #5803 - dwijnand:dependabot/cargo/crossbeam-utils-0.5, r=matklad

Upgrade to crossbeam-utils's -new 0.5 API

Supersedes #5800

Upgrade to crossbeam-utils's -new 0.5 API

Fix minor typo in the book.

Fix `test --doc` with incompatible lib types.

When I recently changed the doctest handling, I forgot to check the lib type in
the `test --doc` scenario.

I also added the package name to a nearby error message, since it can be
confusing in a workspace setting.

Update crossbeam-utils requirement to 0.5

Updates the requirements on [crossbeam-utils](https://github.com/crossbeam-rs/crossbeam-utils) to permit the latest version.
- [Release notes](https://github.com/crossbeam-rs/crossbeam-utils/releases)
- [Changelog](https://github.com/crossbeam-rs/crossbeam-utils/blob/master/CHANGELOG.md)
- [Commits](https://github.com/crossbeam-rs/crossbeam-utils/commits/v0.5.0)

Signed-off-by: dependabot[bot] <support@dependabot.com>

Auto merge of #5794 - Nemo157:rustdoc-rename-extern, r=alexcrichton

Apply dependency renamings when running rustdoc

Fixes #5792

Auto merge of #5790 - dwijnand:dependabot/cargo/crossbeam-0.4, r=alexcrichton

Upgrade to crossbeam 0.4

Supersedes #5789

Switch to crossbeam_utils crate, sidesteppin

Auto merge of #5791 - dwijnand:oneline-files, r=alexcrichton

Declare one-line files on one line, in test projects

Builds on #5787
Fixes #5745 unless @alexcrichton feels more can be done there.

Auto merge of #5787 - dwijnand:dedup-manifest-further, r=alexcrichton

Deduplicate a bunch more manifests in test code

Wanted to deduplicate the "bar" manifest files too, and found I hadn't even done build.rs.

Apply dependency renamings when running rustdoc

Fixes #5792

Update the minimal parking_lot_core version

Declare one-line write_all contents on one line, too

Declare one-line files on one line, in test projects

Migrate to crossbeam's new 0.4 API

Update crossbeam requirement to 0.4

Updates the requirements on [crossbeam](https://github.com/crossbeam-rs/crossbeam) to permit the latest version.
- [Release notes](https://github.com/crossbeam-rs/crossbeam/releases)
- [Changelog](https://github.com/crossbeam-rs/crossbeam/blob/master/CHANGELOG.md)
- [Commits](https://github.com/crossbeam-rs/crossbeam/commits)

Signed-off-by: dependabot[bot] <support@dependabot.com>

Dedup a bunch more manifest

Replace const BASIC_MANIFEST with basic_manifest("foo", "0.0.1")

Auto merge of #5782 - dwijnand:dedup-manifest, r=alexcrichton

Add a default template for Cargo.toml

Fixes #5743

r? @alexcrichton

Auto merge of #5621 - knight42:cargo-search-relaced-registry, r=alexcrichton

Update replaced registry before search

Close #5550.

It seems that updating the replaced registry before search has not been well considered in cargo and I have to add a function to trait `core::source::Source` to get the replaced `SourceId`.

I am not sure whether this is a good design, any advice is welcome.

Drop now unnecessary basic manifests

Auto merge of #5757 - Eh2406:minimal-versions-build, r=alexcrichton

Minimal versions build

This is a conceptual rebase of #5275, to reiterate:
Big thanks to @klausi for doing most of the work!
Thanks to @matklad for pointing out that we could finish it.

I don't know if I have the Travis config quite correct, advice definitely wellcome!

edit: closes #5275

update curl so we don't need so may hacks

Auto merge of #5779 - alexcrichton:msg, r=dwijnand

Fix a formatting of a cargo fix message

Something I saw in the report of https://github.com/rust-lang/cargo/issues/5775

Opt-out all other failing tests

Looks like cargo traverses the filesystem & fails if it runs into a
Cargo.toml that doesn't declare a target.  I couldn't find a nice way to
re-engineer the test to avoid this issue.  So I'll leave that as someone
else's exercise.