3a06fde076
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.
Cargo
Cargo downloads your Rust project’s dependencies and compiles your project.
Learn more at https://doc.rust-lang.org/cargo/
Code Status
Code documentation: https://docs.rs/cargo/
Installing Cargo
Cargo is distributed by default with Rust, so if you've got rustc installed
locally you probably also have cargo installed locally.
Compiling from Source
Cargo requires the following tools and packages to build:
pythoncurl(on Unix)cmake- OpenSSL headers (only for Unix, this is the
libssl-devpackage on ubuntu) cargoandrustc
First, you'll want to check out this repository
git clone https://github.com/rust-lang/cargo
cd cargo
With cargo already installed, you can simply run:
cargo build --release
Adding new subcommands to Cargo
Cargo is designed to be extensible with new subcommands without having to modify Cargo itself. See the Wiki page for more details and a list of known community-developed subcommands.
Releases
High level release notes are available as part of Rust's release notes. Cargo releases coincide with Rust releases.
Reporting issues
Found a bug? We'd love to know about it!
Please report all issues on the github issue tracker.
Contributing
See CONTRIBUTING.md. You may also find the arhitecture documentation useful (ARCHITECTURE.md).
License
Cargo is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT for details.
Third party software
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/).
In binary form, this product includes software that is licensed under the terms of the GNU General Public License, version 2, with a linking exception, which can be obtained from the upstream repository.
See LICENSE-THIRD-PARTY for details.