bors [Tue, 27 Mar 2018 13:58:26 +0000 (13:58 +0000)]
Auto merge of #5249 - alexcrichton:run-rustc-less, r=matklad
Run `rustc` for information fewer times
Currently if you pass `--target` the same as rustc's host Cargo will run `rustc`
on extra time to learn information, but we only need to run it once to learn
such information!
Alex Crichton [Tue, 27 Mar 2018 11:55:23 +0000 (04:55 -0700)]
Run `rustc` for information fewer times
Currently if you pass `--target` the same as rustc's host Cargo will run `rustc`
on extra time to learn information, but we only need to run it once to learn
such information!
bors [Mon, 26 Mar 2018 13:00:26 +0000 (13:00 +0000)]
Auto merge of #5228 - phil-opp:target-spec, r=alexcrichton
Add support for absolute target.json paths
Builds upon https://github.com/rust-lang/rust/pull/49019 with the goal to provide a solution to https://github.com/rust-lang/cargo/issues/4905.
This PR does two things:
~~1. It appends a hash of the target path to the target folder name if a `*.json` path is passed as `--target`, like it's done in https://github.com/rust-lang/rust/pull/49019. This helps differentiating targets with the same JSON file name and avoids sysroot clashes in `xargo`.~~ See https://github.com/rust-lang/cargo/pull/5228#discussion_r176827531
2. It canonicalizes the passed target path (if it's a `*.json` path), so that the path stays valid when building dependencies and setting the `RUST_TARGET_PATH` environment variable is no longer necessary.
bors [Sat, 24 Mar 2018 16:59:59 +0000 (16:59 +0000)]
Auto merge of #5213 - Eh2406:faster_resolver, r=alexcrichton
Faster resolver: use a inverse-index to not activate the causes of conflict
This adds a test for https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286 with two extensions that make it harder. It is the last reproducible and in the wild exponentially slow resolution (that I have found).
The problem in the test is `backtrack_trap0 = "*"` is a lot of ways of saying `constrained = ">=1.1.0, <=2.0.0"` but `constrained= "2.0.1"` is already picked. Only then to try and solve `constrained= "~1.0.0"` which is incompatible. Our parent knows that we have been poisoned, and wont try to activate us again. Because of the order we evaluate deps we end up backtracking to where `constrained: 1.1.0` is set instead of our parent. And so the poisoning does not help. This is harder then https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286 because:
1. Having multiple semver compatible versions of constrained in play makes for a lot more bookkeeping. Specifically bookkeeping I forgot when I first submitted this PR.
2. The problematic dependencies are added deep in a combinatorial explosion of possibilities. So if we don't correctly handle caching that `backtrack_trap0 = "*"` is doomed then we will never finish looking thru the different possibilities for `level0 = "*"`
This PR also includes a proof of concept solution for the test, which proves that it does solve https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286. The added code is tricky to read. It also adds a `O(remaining_deps)` job to every activation on the happy path, slower if the `past_conflicting_activations` is not empty.
bors [Fri, 23 Mar 2018 15:28:44 +0000 (15:28 +0000)]
Auto merge of #5233 - lukaslueg:issue5229, r=matklad
Assert Dependency::name is never empty, prevent 'install ""' from crashing
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`.
Lukas Lueg [Fri, 23 Mar 2018 14:26:50 +0000 (15:26 +0100)]
Assert that Dependency::name is never empty, prevent 'install ""' from crashing
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`.
bors [Thu, 22 Mar 2018 14:07:49 +0000 (14:07 +0000)]
Auto merge of #5217 - matklad:known-crate-types, r=alexcrichton
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 :)
```
bors [Wed, 21 Mar 2018 14:19:11 +0000 (14:19 +0000)]
Auto merge of #5186 - infinity0:stricter-need-dev-deps, r=alexcrichton
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.
bors [Wed, 21 Mar 2018 13:56:00 +0000 (13:56 +0000)]
Auto merge of #5204 - lukaslueg:issue5199, r=alexcrichton
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?
Aleksey Kladov [Wed, 21 Mar 2018 07:54:15 +0000 (10:54 +0300)]
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.
bors [Tue, 20 Mar 2018 19:05:44 +0000 (19:05 +0000)]
Auto merge of #5215 - alexcrichton:update-version, r=matklad
Don't require `cargo update` when bumping versions
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.
Alex Crichton [Tue, 20 Mar 2018 18:38:25 +0000 (11:38 -0700)]
Don't require `cargo update` when bumping versions
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.
`.args(&args[1..])` was copied directly from the docopt implementation, but there, `args[0]` was the path to `cargo` and not the name of subcommand, ie, `args` were *original* arguments for Cargo as a whole.
Alex Crichton [Thu, 15 Mar 2018 22:53:21 +0000 (15:53 -0700)]
Add some documentation to the resolver
This is currently my best-effort attempt to document various portions of the
resolver with the logic that's been added recently. It at least helped me
understand a bit what was going on so I hope it can help others as well!
bors [Sat, 17 Mar 2018 17:49:24 +0000 (17:49 +0000)]
Auto merge of #5187 - Eh2406:faster_resolver, r=alexcrichton
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.
bors [Fri, 16 Mar 2018 15:08:24 +0000 (15:08 +0000)]
Auto merge of #5196 - matklad:clapclapclap, r=alexcrichton
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 :)
Aleksey Kladov [Fri, 16 Mar 2018 14:35:13 +0000 (17:35 +0300)]
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.
bors [Thu, 15 Mar 2018 20:17:46 +0000 (20:17 +0000)]
Auto merge of #5188 - alexcrichton:urgh-again, r=matklad
Add a synthetic dependency on num-traits
Right now the rust-lang/rust integration is compiling Cargo twice on dist
builds, once for Cargo and once for the RLS. This is due to a dependency of
Cargo being recompiled with different features when used from the RLS or not.
For now paper over this problem with a synthetic dependency to prevent Cargo
from being compiled twice.
Alex Crichton [Thu, 15 Mar 2018 18:00:32 +0000 (11:00 -0700)]
Add a synthetic dependency on num-traits
Right now the rust-lang/rust integration is compiling Cargo twice on dist
builds, once for Cargo and once for the RLS. This is due to a dependency of
Cargo being recompiled with different features when used from the RLS or not.
For now paper over this problem with a synthetic dependency to prevent Cargo
from being compiled twice.
Ximin Luo [Thu, 15 Mar 2018 15:57:58 +0000 (16:57 +0100)]
Rename stuff for clarity
- generate_{auto => default}_target since it matches on CompileFilter::Default
- CompileFilter::{matches => target_run} to make it clear it only affects `cargo run`
- Add a comment pointing to generate_target for other subcommands
bors [Thu, 15 Mar 2018 15:22:32 +0000 (15:22 +0000)]
Auto merge of #5180 - alexcrichton:transitive-update, r=matklad
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!
projects / cargo.git / log