The new `mode` for the library dependency is dependent on the library target
rather than the target which is the reason for the dependency on the library!
Closesrust-lang/rust#50640
Add --build-plan for 'cargo build'
With 'cargo build --build-plan', cargo does not actually run any
commands, but instead prints out what it would have done in the form of
a JSON data structure.
Fixes#3815
This changes it so that only top-level targets requested on the command-line will be included in the output directory. Dependencies are no longer included.
Fixes#5444.
With 'cargo build --build-plan', cargo does not actually run any
commands, but instead prints out what it would have done in the form of
a JSON data structure.
Fixes#3815
Note: It errors out if multiple overrides match the same package. This could potentially merge the overrides together with a hierarchy similar to CSS specificity. However, that seems overkill for now.
Support crate renames in `cargo metadata`
This adds information about (currently unstable) crate renames to metadata. Unfortunately, we already expose dependencies as a list of package ids (which are strings), so we can't easily add a `rename` field easily. For this reason, I've added a parallel `deps` key, which basically deprecates `dependencies` field.
So, the new format looks like this
```JavaScript
{
"dependencies": [
"bar 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)",
"bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)"
],
"deps": [
{
"extern_crate_name": "baz", // this one is actually renamed
"id": "bar 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)"
},
{
"extern_crate_name": "bar",
"id": "bar 0.1.0 (registry+https://github.com/rust-lang/crates.io-index)"
}
],
"features": [],
"id": "foo 0.5.0 (path+file://[..])"
},
```
Questions:
* Is there a better name for `extern_crate_name`? This name is precise, but it's longer than I like, and might become opaque in meaning if we remove `extern crate` from the language :)
* Should we feature gate this (i.e, only produce `deps` if we have a feature in `Cargo.toml`)? I think the answer is yes, but that'll require threading `Features` to `Workspace`...
r? @alexcrichton
The old `dependencies` key in `resolve` is deprecated.
Instead, the new `deps` key introduced which lists dependencies kinds
(dev/build/normal) as well as `extern crate` name for the dep.
This commit cops out trying to fix `rename_with_link_search_path` by simply
adding a loop on Windows to retry the operation that looks to need retrying.
FIx false positive warning
We warn if a feature was specified corresponding to a dependency which
is not optional. However, a dependency can be both optional and
required, and we shouldn't warn in that case.
cc https://github.com/rust-lang/cargo/pull/5480
r? @alexcrichton
We warn if a feature was specified corresponding to a dependency which
is not optional. However, a dependency can be both optional and
required, and we shouldn't warn in that case.
Do not allow running library examples.
This is my first contribution to anything Rust related that I haven't written myself, and I'm not a very proficient Rust programmer (yet), so would love some feedback on improvements.
I also might have solved this the wrong way... 😄Closes#5474
(cc @matklad)
Fix optional deps in multiple sections
This commit fixes an issue where an optional dependency was listed multiple
times in a manifest (multiple sections). This regression was introduced by #5415
and happened because in the resolver we didn't record a `Dependency` as it was
accidentally deduplicated too soon.
The fix here was to ensure that all `Dependency` annotations make their way into
`Resolve` now that we rely on the listed `Dependency` values for correctness.
Closes#5475
This commit fixes an issue where an optional dependency was listed multiple
times in a manifest (multiple sections). This regression was introduced by #5415
and happened because in the resolver we didn't record a `Dependency` as it was
accidentally deduplicated too soon.
The fix here was to ensure that all `Dependency` annotations make their way into
`Resolve` now that we rely on the listed `Dependency` values for correctness.
Closes#5475
Try & simplify Registry vs Source confusion
Refs #3006.
I tried to go further and replace references of `Registry` with `PackageRegistry`, but I ran into lifetime issue in `ops::resolve_with_previous` which I think has to do with no longer passing `PackageRegistry` as a `Registry` trait object (with a new and distinct lifetime).
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.
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.
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.
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)
```
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)
```
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...
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
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
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
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.
Revert "Enable new behavior of `--feature`"
This reverts commit 038eec5cb3.
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
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
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
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>
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.
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.
In Rust 2015 absence of the configuration makes it default to not
include auto-discovered targets (i.e false), with a warnings message.
In Rust 2018 absence makes it default to include auto-discovered
targets (i.e true).
Fixes#5330
Print "Checking" for cargo check
I often alternate between `check` and `build` and I'd like to be able to tell which is currently happening (short-term memory being what it is, and "compiling" implying to me that codegen is occurring). Changing the message to "Checking" seemed to be reasonable (and there was precedent for `doc` with "Documenting").
Enable new behavior of `--feature`
So far, the feedback on https://internals.rust-lang.org/t/help-us-test-the-breaking-bug-fix-to-cargo-features/7317 has been positive, so here's a PR to try this in nightly.
Note that the logic is slightly tweak for the case `cargo build -p not-a-workspace-member`: we want not only to resolve all ws members in this case, but to enable all of their features as well!
As a sanity check, this seems to be forward compatible with further improvements to features:
1) when we solve the grand bug of features being unified across the whole workspace, `cargo build -p not-a-member` would hopefully just work without additional contortions.
2) we might add a way to specify features per package, like `cargo build -p foo -p bar --features "foo/serde bar/serde"`
cargotest: Fix `with_*_does_not_contain` to support `[..]` and macro matching.
I changed it so that it is essentially the opposite of `with_*_contains` to keep it symmetric.
Any in-flight PRs using the old style will need to be updated (else they will incorrectly silently pass). Alternatively, we could rename the method to avoid that.
The following tests contained brackets, so they were not checking what they thought they were checking. I did a cursory look at them, but perhaps someone else could double-check that they make sense. Asserting what *doesn't* happen can be tricky since there is an infinite number of things that won't happen. Preferably a test would assert that it appears in one scenario and not another (like `incremental_profile` does), but some of them don't or can't.
```
build::incremental_profile
build::incremental_config
build::cargo_compile_with_workspace_excluded
build::build_all_exclude
build::targets_selected_default
check::targets_selected_default
check::check_filters
rustc::targets_selected_default
rustc_info_cache::rustc_info_cache
warn_on_failure::no_warning_on_bin_failure
warn_on_failure::warning_on_lib_failure
```
BTW, would you be interested in a PR that adds some documentation to `cargotest`?
I've discovered things I didn't know where there. I think some docstrings on some of the methods, and a short guide for new contributors would be helpful.
Rustc cache
This implements rustc caching, to speed-up no-op builds.
The cache is per-project, and stored in `target` directory. To implement this, I had to move `rustc` from `Config` down to `BuildConfig`.
closes https://github.com/rust-lang/cargo/issues/5315
Historically, feature-related flags like `--all-features`,
`--no-default-features` and `--features` operated on the *current*
package. That is, `cargo --package foo --feature feat` would activate
`feat` for the package at the current working directory, and not for the
`foo` package. `-Z package-features` flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:
* `--feature` flag affects the selected package. It is an error to
specify `--feature` with more than a single `-p`, or with `-p` outside
workspace (the latter could work in theory, but would be hard to
implement).
* `--all-features` and `--no-default-features` affect all selected
packages, and not the one at cwd.
* The package in `cwd` is not implicitly enabled when doing feature
selection. That is, `cargo build -Z package-features -p foo` could
select *less* features for various packages than `cargo build -p foo`.
This commit extends the fix in #5288 by moving the logic added farther up in the
loop over package dependencies. This means that we won't recursively look at
optional/dev path dependencies which aren't members of the workspace. This
should fix the new issue that came up in #5257Closes#5257
Less aggressively poison sources on builds
Discovered in #5257 the changes in #5215 were slightly too aggressively
poisoning sources to require updates, thinking that a manifest changed when it
actually hadn't.
Non-workspace-member path dependencies with optional/dev-dependencies
don't show up in the lock file, so the previous logic would recognize this and
think that the dependency missing from the lock file was just added and would
require a registry update.
The fix in this commit effectively just skips all of these dependencies in
non-workspace members. This means that this will be slightly buggy if an
optional dependency that's activated is added, but that's hopefully something we
can tackle later.
Closes#5257
Discovered in #5257 the changes in #5215 were slightly too aggressively
poisoning sources to require updates, thinking that a manifest changed when it
actually hadn't.
Non-workspace-member path dependencies with optional/dev-dependencies
don't show up in the lock file, so the previous logic would recognize this and
think that the dependency missing from the lock file was just added and would
require a registry update.
The fix in this commit effectively just skips all of these dependencies in
non-workspace members. This means that this will be slightly buggy if an
optional dependency that's activated is added, but that's hopefully something we
can tackle later.
Closes#5257
cargo_new: remove redundant leading new lines from ignore files
Only add a leading new line in `.gitignore`/`.hgignore`/`.ignore` files when
the file existed before `cargo new`.
Fixes#5265.
fix#2773 with new precise encode
Changed the precise encode from <pkg>=<precise> to <pkg>=<present_version>-><future_version> in order to check the correct requirements.
cc @lu-zero
feat(resolver): Add CLI option to resolve minimal version dependencies
Fixes#4100
Test cases are still missing. We need to come up with a plan what cases we want to cover.
Thanks a lot to @Eh2406 for very helpful instructions to kick this off.
An explicit `cargo install ""` would cause clap to pass an empty crate-name,
leading to a panic(). We now assert() that Dependency::name is never the
empty string and prevent the situation in the first place by not allowing
the crate-name to be empty for `install`.
Fixes#5229
Preprobe info for known crate type
Previously, we've calculated the set of crate types to learn about by
recursively walking the graph of units. However, to actually know
dependencies of a unit exactly, we must know target specific info, and
we don't know it at this moment (in fact, we are trying calculating it).
Note that crate-type calculation is already lazy, we don't have to calc
all crate-types upfront. So, let's just scrape this info once for
well-known crate types, and fill whatever is left lazily.
@alexcrichton would this approach work at all? I think it would, if `KNOWN_CRATE_TYPES` are all available for all target-tripples we support. Is it a valid assumption?
The larger picture is that I am trying to make unit dependency resolution eager and move it into the separate file. I even got something working, but I have to run dependency resolution three times, because it is not exactly idempotent for various reasons, including this target-info stuff :)
```
cx.prepare()?;
cx.build_unit_map(units.clone())?; // resolve dependencies
cx.probe_target_info(&units)?;
cx.build_unit_map(units.clone())?; // resolve again
cx.build_used_in_plugin_map(&units)?;
custom_build::build_map(&mut cx, &units)?;
cx.build_unit_map(units.clone())?; // and resolve one final time :)
```
Stricter need_dev_deps behaviour
The previous PR (#5012) contained an unnecessary work-around for behaviour of `--all-targets` that was misunderstood. This PR removes that work-around and adds some tests and comments to clarify the behaviour for future contributors, which may help to make easier a future fix for #5177 and #5178.
Do not allow crate-type or proc-macro for [[bin]]-targets
Fixes#5199
This simply disallows `proc-macro` and `crate-type` to be set to anything for binary targets. Is this the best way to go or does a warning about the unused setting suffice?
Previously, we've calculated the set of crate types to learn about by
recursively walking the graph of units. However, to actually know
dependencies of a unit exactly, we must know target specific info, and
we don't know it at this moment (in fact, we are trying calculating it).
Note that crate-type calculation is already lazy, we don't have to calc
all crate-types upfront. So, let's just scrape this info once for
well-known crate types, and fill whatever is left lazily.
One historical annoyance I've always had with Cargo that I've found surprising
is that in some situations when you bump version numbers you'll have to end up
running `cargo update` later on to get everything to build. You get pretty wonky
error messages in this case as well saying a package doesn't exist when it
clearly does at a particular location!
I've had difficulty historically nailing down a test case for this but it looks
like we ironically already had one in our test suite and I also jury-rigged up
one from a case I ran into in the wild today.
Faster resolver: clean code and the `backtrack_stack`
This is a small extension to #5168 and is inspired by https://github.com/rust-lang/cargo/pull/4834#issuecomment-363518370
After #5168 these work (and don't on cargo from nightly.):
- `safe_core = "=0.22.4"`
- `safe_vault = "=0.13.2"`
But these don't work (and do on cargo from this PR.)
- `crust = "=0.24.0"`
- `elastic = "=0.3.0"`
- `elastic = "=0.4.0"`
- `elastic = "=0.5.0"`
- `safe_vault = "=0.14.0"`
It took some work to figure out why they are not working, and make a test case.
This PR remove use of `conflicting_activations` before it is extended with the conflicting from next.
https://github.com/rust-lang/cargo/pull/5187#issuecomment-373830919
However the `find_candidate(` is still needed so it now gets the conflicting from next before being called.
It often happens that the candidate whose child will fail leading to it's failure, will have older siblings that have already set up `backtrack_frame`s. The candidate knows that it's failure can not be saved by its siblings, but sometimes we activate the child anyway for the error messages. Unfortunately the child does not know that is uncles can't save it, so it backtracks to one of them. Leading to a combinatorial loop.
The solution is to clear the `backtrack_stack` if we are activating just for the error messages.
Edit original end of this message, no longer accurate.
#5168 means that when we find a permanent problem we will never **activate** its parent again. In practise there afften is a lot of work and `backtrack_frame`s between the problem and reactivating its parent. This PR removes `backtrack_frame`s where its parent and the problem are present. This means that when we find a permanent problem we will never **backtrack** into it again.
An alternative is to scan all cashed problems while backtracking, but this seemed more efficient.
Fix a regression with parsing multivalue options
By default, clap interprets
```
cargo run --bin foo bar baz
```
as
```
cargo run --bin foo --bin bar --bin baz
```
This behavior is different from docopt and does not play nicely with
positional arguments at all. Luckily, clap has a flag to get the
behavior we want, it just not the default! It will become the default in
the next version of clap, but, until that time, we should be careful
when using the combination of `.long`, `.value_name` and
`.multiple(true)`, and don't forget to specify `.number_of_values(1)` as
well.
@alexcrichton I'd love to merge this fix before updating cargo at rust-lang/rust :)
By default, clap interprets
```
cargo run --bin foo bar baz
```
as
```
cargo run --bin foo --bin bar --bin baz
```
This behavior is different from docopt and does not play nicely with
positional arguments at all. Luckily, clap has a flag to get the
behavior we want, it just not the default! It will become the default in
the next version of clap, but, until that time, we should be careful
when using the combination of `.long`, `.value_name` and
`.multiple(true)`, and don't forget to specify `.number_of_values(1)` as
well.
Don't abort resolution on transitive updates
This commit is directed at fixing #4127, allowing the resolver to automatically
perform transitive updates when required. A few use casese and tagged links are
hanging off #4127 itself, but the crux of the issue happens when you either add
a dependency or update a version requirement in `Cargo.toml` which conflicts
with something listed in your `Cargo.lock`. In this case Cargo would previously
provide an obscure "cannot resolve" error whereas this commit updates Cargo to
automatically perform a conservative re-resolution of the dependency graph.
It's hoped that this commit will help reduce the number of "unresolvable"
dependency graphs we've seen in the wild and otherwise make Cargo a little more
ergonomic to use as well. More details can be found in the source's comments!
Closes#4127
This commit is directed at fixing #4127, allowing the resolver to automatically
perform transitive updates when required. A few use casese and tagged links are
hanging off #4127 itself, but the crux of the issue happens when you either add
a dependency or update a version requirement in `Cargo.toml` which conflicts
with something listed in your `Cargo.lock`. In this case Cargo would previously
provide an obscure "cannot resolve" error whereas this commit updates Cargo to
automatically perform a conservative re-resolution of the dependency graph.
It's hoped that this commit will help reduce the number of "unresolvable"
dependency graphs we've seen in the wild and otherwise make Cargo a little more
ergonomic to use as well. More details can be found in the source's comments!
Closes#4127Closes#5182
Don't rewrite dep-info files if they don't change
Similar to how we treat lock files, read the contents, compare, and if they're
the same don't actually write the file.
Closes#5172
Copy `.pdb` files to `target` directory
`.pdb` files are for windows debug info (unlike on linux, debug info is
in a separate file). Windows executable actually hard-code paths to
`.pdb` files, so debugging mvsc rust programs works even without this
patch. However, if you want to distribute the executable to other
machines, you'd better distribute both `foo.exe` and `foo.pdb`, because
absolute paths won't work on another machine. Having same-named .pdb
file alongside the binary would work though.
closes#4960
Depending on the OS, there might be an additional artifacts for
debuginfo (dSYM folder for macs, .pbd file for windows). Given that we
can't disable `.pdb` for windows[1], let's just ignore all filenames!
[1]: https://github.com/rust-lang/rust/pull/28505)
`.pdb` files are for windows debug info (unlike on linux, debug info is
in a separate file). Windows executable actually hard-code paths to
`.pdb` files, so debugging mvsc rust programs works even without this
patch. However, if you want to distribute the executable to other
machines, you'd better distribute both `foo.exe` and `foo.pdb`, because
absolute paths won't work on another machine. Having same-named .pdb
file alongside the binary would work though.
closes#4960
Faster resolver: Cache past conflicting_activations, prevent doing the same work repeatedly.
This work is inspired by @alexcrichton's [comment](https://github.com/rust-lang/cargo/issues/4066#issuecomment-303912744) that a slow resolver can be caused by all versions of a dependency being yanked. Witch stuck in my brain as I did not understand why it would happen. If a dependency has no candidates then it will be the most constrained and will trigger backtracking in the next tick. Eventually I found a reproducible test case. If the bad dependency is deep in the tree of dependencies then we activate and backtrack `O(versions^depth)` times. Even tho it is fast to identify the problem that is a lot of work.
**The set up:**
1. Every time we backtrack cache the (dep, `conflicting_activations`).
2. Build on the work in #5000, Fail to activate if any of its dependencies will just backtrack to this frame. I.E. for each dependency check if any of its cached `conflicting_activations` are already all activated. If so we can just skip to the next candidate. We also add that bad `conflicting_activations` to our set of `conflicting_activations`, so that we can...
**The pay off:**
If we fail to find any candidates that we can activate in lite of 2, then we cannot be activated in this context, add our (dep, `conflicting_activations`) to the cache so that next time our parent will not bother trying us.
I hear you saying "but the error messages, what about the error messages?" So if we are at the end `!has_another` then we disable this optimization. After we mark our dep as being not activatable then we activate anyway. It won't resolve but it will have the same error message as before this PR. If we have been activated for the error messages then skip straight to the last candidate, as that is the only backtrack that will end with the user.
I added a test in the vain of #4834. With the old code the time to run was `O(BRANCHING_FACTOR ^ DEPTH)` and took ~3min with DEPTH = 10; BRANCHING_FACTOR = 5; with the new code it runs almost instantly with 200 and 100.
Clap
Reopening of #5129
So, looks like all tests are 🍏 on my machine!
I definitely want to refactor it some more, and also manually checked that we haven't regressed any help messages, but all the major parts are in place already.
Error message for package "depends on itself" lists the packages in the cycle.
I got a cycle while trying to build someone else's code and cargo's error message didn't point me in the right direction, just mentioned there was a cycle. I thought we could be a bit more helpful.
Don't know what you think of {:#?} as the display but it seemed minimal code so I thought I'd start with that. I could compress the output to one package per line if preferred.
Don't require dev-dependencies when not needed in certain cases
Specifically, when running `cargo install` and add a flag for this behaviour in `cargo build`.
This closes#4988.
Drop ignored tests
r? @alexcrichton
These tests are ignored, so its better to remove them. `run` does not supports `--bins` argument, so I've left a single test that checks specifically for this.
cc https://github.com/rust-lang/cargo/pull/3901
Try a lot harder to recover corrupt git repos
We've received a lot of intermittent bug reports historically about corrupt git
repositories. These inevitably happens as Cargo is ctrl-c'd or for whatever
other reason, and to provide a better user experience Cargo strives to
automatically handle these situations by blowing away the old checkout for a new
update.
This commit adds a new test which attempts to pathologically corrupt a git
database and checkout in an attempt to expose bugs in Cargo. Sure enough there
were some more locations that we needed to handle gracefully for corrupt git
checkouts. Notable inclusions were:
* The `fetch` operation in libgit2 would fail due to corrupt references. This
starts by adding an explicit whitelist for classes of errors coming out of
`fetch` to auto-retry by blowing away the repository. We need to be super
careful here as network errors commonly come out of this function and we don't
want to too aggressively re-clone.
* After a `fetch` succeeded a repository could fail to actual resolve a
git reference to the actual revision we want. This indicated that we indeed
needed to blow everything away and re-clone entirely again.
* When creating a checkout from a database the `reset` operation might fail due
to a corrupt local database of the checkout itself. If this happens we needed
to just blow it away and try again.
There's likely more lurking situations where we need to re-clone but I figure we
can discover those over time.
We've received a lot of intermittent bug reports historically about corrupt git
repositories. These inevitably happens as Cargo is ctrl-c'd or for whatever
other reason, and to provide a better user experience Cargo strives to
automatically handle these situations by blowing away the old checkout for a new
update.
This commit adds a new test which attempts to pathologically corrupt a git
database and checkout in an attempt to expose bugs in Cargo. Sure enough there
were some more locations that we needed to handle gracefully for corrupt git
checkouts. Notable inclusions were:
* The `fetch` operation in libgit2 would fail due to corrupt references. This
starts by adding an explicit whitelist for classes of errors coming out of
`fetch` to auto-retry by blowing away the repository. We need to be super
careful here as network errors commonly come out of this function and we don't
want to too aggressively re-clone.
* After a `fetch` succeeded a repository could fail to actual resolve a
git reference to the actual revision we want. This indicated that we indeed
needed to blow everything away and re-clone entirely again.
* When creating a checkout from a database the `reset` operation might fail due
to a corrupt local database of the checkout itself. If this happens we needed
to just blow it away and try again.
There's likely more lurking situations where we need to re-clone but I figure we
can discover those over time.
backtrack if can not activate
This is a fix for #4347
Unfortunately this too regressed error messages for the case that you specified a dependency feature that does not exist.
@alexcrichton advice on improving the message?
