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!
Closes#6780
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.
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).
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.”
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.
```diff
PackageId {
name: "foo",
version: "1.0.0",
- source: "registry `https://github.com/rust-lang/crates.io-index`"
+ source: "registry `https://github.com/rust-lang/crates.io-index`",
}
```
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.
The standard library is planning to begin emitting trailing commas in
multiline Debug representations to align with the dominant style in
modern Rust code.
PackageId {
name: "foo",
version: "1.0.0",
- source: "registry `https://github.com/rust-lang/crates.io-index`"
+ source: "registry `https://github.com/rust-lang/crates.io-index`",
}
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.
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.
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.
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.
Don't include metadata in wasm binary examples.
This removes the metadata hash from wasm example binaries, and consequently also includes the `.wasm` files in the artifact JSON message.
Closes#6810.
I renamed a method and added a new one to maybe make things a little clearer. This cannot be easily tested (see #4973).
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.
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.
Fixes#6795.
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.
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.
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.
Closes#6498.
Closes#6397.
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?
Closes#5145
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.
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.
Closes#4892
Fix member_manifest_version_error accessing the network.
This test was updating the registry via github. Add a `.cargo/config` file so that it doesn't.
