Alex Crichton [Sat, 4 Aug 2018 15:44:16 +0000 (08:44 -0700)]
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.
bors [Thu, 2 Aug 2018 14:57:35 +0000 (14:57 +0000)]
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!
Alex Crichton [Wed, 1 Aug 2018 00:01:09 +0000 (17:01 -0700)]
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!
bors [Wed, 1 Aug 2018 16:39:58 +0000 (16:39 +0000)]
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?
bors [Wed, 1 Aug 2018 15:51:56 +0000 (15:51 +0000)]
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.
bors [Wed, 1 Aug 2018 02:52:35 +0000 (02:52 +0000)]
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.
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`.
Alex Crichton [Tue, 31 Jul 2018 20:08:46 +0000 (13:08 -0700)]
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.
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`
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!
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!
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)
Alex Crichton [Thu, 26 Jul 2018 19:56:32 +0000 (12:56 -0700)]
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!
Alex Crichton [Sat, 28 Jul 2018 20:22:32 +0000 (13:22 -0700)]
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!
Alex Crichton [Sat, 28 Jul 2018 17:38:34 +0000 (10:38 -0700)]
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 #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.
Igor Matuszewski [Sun, 29 Jul 2018 19:18:36 +0000 (21:18 +0200)]
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 #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 #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.
Without Boats [Tue, 17 Jul 2018 06:27:43 +0000 (02:27 -0400)]
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.
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)
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)
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.
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!
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.