Auto merge of #6832 - alexcrichton:freshness, r=ehuss
Remove `Freshness` from `DependencyQueue`
Ever since the inception of Cargo and the advent of incremental
compilation at the crate level via Cargo, Cargo has tracked whether it
needs to recompile something at a unit level in its "dependency queue"
which manages when items are ready for execution. Over time we've fixed
lots and lots of bugs related to incremental compilation, and perhaps
one of the most impactful realizations was that the model Cargo started
with fundamentally doesn't handle interrupting Cargo halfway through and
resuming the build later.
The previous model relied upon implicitly propagating "dirtiness" based
on whether the one of the dependencies of a build was rebuilt or not.
This information is not available, however, if Cargo is interrupted and
resumed (or performs a subset of steps and then later performs more).
We've fixed this in a number of places historically but the purpose of
this commit is to put a nail in this coffin once and for all.
Implicit propagation of whether a unit is fresh or dirty is no longer
present at all. Instead Cargo should always know, irrespective of it's
in-memory state, whether a unit needs to be recompiled or not. This
commit actually turns up a few bugs in the test suite, so later commits
will be targeted at fixing this.
Note that this required a good deal of work on the `fingerprint` module
to fix some longstanding bugs (like #6780) and some serious hoops had to
be jumped through for others (like #6779). While these were fallout from
this change they weren't necessarily the primary motivation, but rather
to help make `fingerprints` a bit more straightforward in what's an
already confusing system!
Alex Crichton [Tue, 9 Apr 2019 18:37:31 +0000 (11:37 -0700)]
Purge mtime information from `Fingerprint`
This has proven to be a very unreliable piece of information to hash, so
let's not! Instead we track what files are supposed to be relative to,
and we check both mtimes when necessary.
Alex Crichton [Fri, 5 Apr 2019 19:54:50 +0000 (12:54 -0700)]
Remove `Freshness` from `DependencyQueue`
Ever since the inception of Cargo and the advent of incremental
compilation at the crate level via Cargo, Cargo has tracked whether it
needs to recompile something at a unit level in its "dependency queue"
which manages when items are ready for execution. Over time we've fixed
lots and lots of bugs related to incremental compilation, and perhaps
one of the most impactful realizations was that the model Cargo started
with fundamentally doesn't handle interrupting Cargo halfway through and
resuming the build later.
The previous model relied upon implicitly propagating "dirtiness" based
on whether the one of the dependencies of a build was rebuilt or not.
This information is not available, however, if Cargo is interrupted and
resumed (or performs a subset of steps and then later performs more).
We've fixed this in a number of places historically but the purpose of
this commit is to put a nail in this coffin once and for all.
Implicit propagation of whether a unit is fresh or dirty is no longer
present at all. Instead Cargo should always know, irrespective of it's
in-memory state, whether a unit needs to be recompiled or not. This
commit actually turns up a few bugs in the test suite, so later commits
will be targeted at fixing this.
Note that this required a good deal of work on the `fingerprint` module
to fix some longstanding bugs (like #6780) and some serious hoops had to
be jumped through for others (like #6779). While these were fallout from
this change they weren't necessarily the primary motivation, but rather
to help make `fingerprints` a bit more straightforward in what's an
already confusing system!
Auto merge of #6824 - ehuss:improve-test-rerun-hint, r=alexcrichton
Improve error message to rerun a test in a workspace.
In a non-virtual workspace, if you run `cargo test --all` and something fails, it tells you to rerun `--test foo`, but if `foo` is not the default, then it won't work without a `-p` flag. This tries to be a little more careful about when `-p` is needed in the hint.
Auto merge of #6798 - ehuss:install-upgrade, r=alexcrichton
Add install-upgrade.
This implements the feature described in #6667. Instead of failing when `cargo install` detects a package is already installed, it will upgrade if the versions don't match, or do nothing (exit 0) if it is considered "up-to-date".
Closes #6667.
Notes:
- This feature rejects ambiguous `--version` input (such as `1.0`). This is not required, but seemed like a reasonable time to make the change.
- There is a slight change to the output on stable which reports what was installed/replaced.
- Added better support for `*` in `--version` (don't show warning).
Auto merge of #6823 - spl:clarify-install-path, r=alexcrichton
Clarify docs of install without <crate>
This is an attempt to clarify the documentation of `install` without `<crate>`. I found it confusing trying to determine to which behavior “this” referred as well as whether “supported” meant “maintained” or “worked.”
Auto merge of #6818 - dtolnay:comma, r=alexcrichton
Accept trailing comma in test of impl Debug for PackageId
The standard library is planning to begin emitting trailing commas in multiline Debug representations to align with the dominant style in modern Rust code -- https://github.com/rust-lang/rust/pull/59076.
For now, change this tests to accept both with and without trailing comma. Once the trailing comma change reaches the stable channel we will be able to remove one of the cases.
David Tolnay [Wed, 3 Apr 2019 20:17:16 +0000 (13:17 -0700)]
Accept trailing comma in test of impl Debug for PackageId
The standard library is planning to begin emitting trailing commas in
multiline Debug representations to align with the dominant style in
modern Rust code.
For now, change this tests to accept both with and without trailing
comma. Once the trailing comma change reaches the stable channel we will
be able to remove one of the cases.
Auto merge of #6814 - ehuss:offline-optional-dep, r=alexcrichton
Resolve: Be less strict while offline.
When offline, the resolver was requiring everything to be downloaded, even dependencies that are not used. This changes it so that the resolver can still resolve unavailable dependencies when offline. This pushes the failure to a later stage of Cargo where it attempts to download the dependency. This makes `-Z offline` work for target-cfg or optional dependencies that are not being used.
Fixes #6014.
This changes the error message significantly for the "unavailable" case (see test diff). I personally think the new error message is clearer, although it is shorter and provides less information. The old error message seemed large and scary, and was a little hard for me to grok. However, I'd be willing to look at tweaking the error behavior if not everyone agrees.
Auto merge of #6776 - Eh2406:resolver-simplification, r=alexcrichton
Resolver: A dep is equivalent to one of the things it can resolve to.
This is a series of small changes to the resolver, each one on its own is not worth the cherne, but somehow all together we can add a new optimization rule. The result is that the test in #6283 is no longer exponencial (still a large polynomial, cubick?) and so N can be bumped from 3 to 20. This also means that we pass with all the cases reported in #6258. Resolution is NP-Hard, so we are moving the slow cases around. To reduce the chance that we will be flooded by new bad cases I run the 4 proptests overnight, and they did not find a new exponencial case.
I would recommend reviewing this commit by commit. As each change is pretty simple on its own, but the mixed diff is harder to follow. This is submitted as one big PR as that is @alexcrichton's preference.
A special thanks to @nex3, our conversation was important in convincing me that several of these changes would be needed even in an eventual PubGrub based system. And, the question "why would PubGrub not have a problem with #6283" was wat crystallized this optimization opportunity in my mind.
Auto merge of #6811 - ehuss:include-proc-macro, r=alexcrichton
Include proc-macros in `build-override`.
This adds proc-macros (and their dependencies) to the `build-override` profile setting. The motivation is that these are all "build time" dependencies, and as such should probably behave the same. See the discussion on the [tracking issue](https://github.com/rust-lang/rust/issues/48683#issuecomment-472705245). My intent is that this paves the way for stabilizing without necessarily waiting for #6577.
The only change here is the line in `with_for_host`, the rest is just renaming for clarity.
This also includes some of the testsuite changes from #6577 to make it easier to check for compiler flags.
Alex Crichton [Mon, 1 Apr 2019 17:22:23 +0000 (10:22 -0700)]
Remove no longer needed fields in `BuildConfig`
Now the fields are just all represented as `rustc_wrapper` which
internally contains all process configuration that's later passed down
to `Rustc` as necessary.
Auto merge of #6800 - ehuss:git-cli-force, r=alexcrichton
Support force-pushed repos with git-fetch-with-cli.
If a git repo had a force push, then the `git-fetch-with-cli` feature would fail to fetch an update. This adds the `--force` flag to force the fetch. There's a bit of a lengthy discussion in the [git docs](https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt-ltrefspecgt) about why this is needed when a refspec is supplied.
I also changed it to remove the `--quiet` flag and to capture the output, which is only displayed on error. I'm not sure what the reasoning for the `--quiet` flag was, but I don't see any harm since the output was previously unused. This can maybe help people debug problems, however in this situation
all you would see is ` ! [rejected] master -> master (non-fast-forward)` which isn't terribly informative.
Auto merge of #6801 - ehuss:install-flags, r=Eh2406
cargo install: Be more restrictive about cli flags.
Several flags in `cargo install` are silently ignored depending on what is used. This adds some validation so that invalid combinations are rejected. I have been sorta confused by these in the past.
- The 3 source flags (`--git`, `--path`, and `--registry`) are mutually exclusive.
- The `--git` flags (branch, tag, rev) are only valid if `--git` is specified.
- `--registry` requires a crate name (otherwise it would be ignored and treated as a path source).
- `--version` is only used when a crate name is specified.
Auto merge of #6806 - ehuss:warn-semver-metadata, r=Eh2406
Warn on version req with metadata.
Metadata in a version requirement (such as `1.0.0+1234`) is ignored. This adds a warning that it will be ignored.
On crates.io I found about 5 crates, plus a few dozen google-* crates (presumably all created by the same person) which have dependencies of this form.
See discussion at https://github.com/rust-lang/cargo/issues/6504#issuecomment-451254084. cc rust-lang/crates.io#1059 for ongoing discussion about what to do about publishing such versions.
Auto merge of #6804 - ehuss:install-path-config2, r=alexcrichton
Allow `cargo install --path P` to load config from P.
`cargo install` was changed to ignore configs except for the home directory (#6026). However, it seems like there are legitimate needs when using `--path`, so allow loading from that path, too.
Auto merge of #6803 - ehuss:doc-open-multi, r=alexcrichton
Allow `cargo doc --open` with multiple packages.
If `cargo doc --open` builds multiple packages, open the first one. This seems pretty natural to me (the first one on the command line, or the first default member if `default-members` is specified, or the root of a workspace). Rustdoc shows a list of crates in the sidebar, so if it doesn't open the one the user wants, it's a trivial matter of clicking on the crate name.
@alexcrichton specifically asked for an error [here](https://github.com/rust-lang/cargo/pull/1828#discussion-diff-39650485). However, at the time I don't think rustdoc dynamically generated the "Crates" listing in the sidebar. Alex, I wonder if your stance still holds?
Auto merge of #6791 - ehuss:unstable-help, r=Eh2406
Add some help and documentation for unstable flags.
This is intended to give a little extra information about unstable flags.
- `-Z help` tells you if you can't use it on stable.
- `-Z help` includes link to the unstable chapter.
- `--out-dir` and `--build-plan` on stable give more information about what channels are and a link to their respective tracking issues. Add links in the man pages, too.
bors [Sun, 31 Mar 2019 21:14:56 +0000 (21:14 +0000)]
Auto merge of #6802 - ehuss:new-empty-email, r=Eh2406
new/init: Don't include email if it is empty.
For `cargo new` or `cargo init`, if the email address is empty, don't include an empty `<>` in the `authors` field in `Cargo.toml`. This can be useful if you want to include an email address in the git config, but you don't want it in new manifest files.
bors [Fri, 29 Mar 2019 12:31:50 +0000 (12:31 +0000)]
Auto merge of #6792 - collin5:patch-1, r=alexcrichton
Fix Init for Fossil SCM project
I believe [here](https://github.com/rust-lang/cargo/pull/6792/files#diff-149dd4362a3b0dc13b113762713119dfL527) we should be checking if `.fossil` doesn't exist instead of the latter!
Eh2406 [Sat, 23 Mar 2019 02:30:06 +0000 (22:30 -0400)]
if we are a descendant of the trigger of the problem.
The best generalization of this is to let things bubble up
and let `jumpback_critical_id` figure this out.
Eh2406 [Mon, 18 Mar 2019 21:40:23 +0000 (17:40 -0400)]
A dep is equivalent to one of the things it can resolve to.
Thus, if all the things it can resolve to have already ben determined
to be conflicting, then we can just say that we conflict with the parent.
Eh2406 [Sat, 16 Mar 2019 13:25:19 +0000 (09:25 -0400)]
move compatible to a type
This makes a O(n^2) loop in the hart of the resolver a O(n) loop,
but n is small and hashing is not free.
So the main reason to do this is to make the code clearer.
bors [Tue, 26 Mar 2019 23:22:07 +0000 (23:22 +0000)]
Auto merge of #6534 - ehuss:meta-deps-name-null, r=alexcrichton
cargo metadata: Don't show `null` deps.
If a package has a dependency without a library target, the "name" field was
showing up as null in `resolve.nodes.deps`. At this time (AFAIK), binary-only
dependencies are always ignored. Instead of making users filter out this entry
(or more commonly, crash), just don't include it.
bors [Tue, 26 Mar 2019 22:25:44 +0000 (22:25 +0000)]
Auto merge of #6785 - ehuss:fingerprint-cleanup, r=dwijnand
Some fingerprint cleanup.
Just a minor cleanup.
Move `CARGO_PKG_*` values from Metadata to Fingerprint (added in #3857). Closes #6208. This prevents stale artifacts from being left behind when these values change. Also tracks changes to the "repository" value (added in #6096).
Remove `edition` as a separate field. It is already tracked in `target`. This was required previously to #5816 which added per-target editions.
Also adds a helper to the testsuite to make globbing easier.