bors [Sat, 3 Mar 2018 21:32:24 +0000 (21:32 +0000)]
Auto merge of #5112 - Eh2406:cache_queries, r=alexcrichton
Cache the query result.
Small performance gain.
In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 1700000 ticks in ~97 sec
After we got to 1700000 ticks in ~92 sec. I just reran and got ~82, so it seems to be unstable.
And query disappears from the flame graph
bors [Fri, 2 Mar 2018 23:37:29 +0000 (23:37 +0000)]
Auto merge of #5110 - alexcrichton:reset-harder, r=matklad
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.
Alex Crichton [Fri, 2 Mar 2018 17:44:47 +0000 (09:44 -0800)]
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.
Eh2406 [Fri, 2 Mar 2018 22:56:36 +0000 (17:56 -0500)]
Cache the query result.
In a test on https://github.com/rust-lang/cargo/issues/4810#issuecomment-357553286
Before we got to 1700000 ticks in ~97 sec
After we got to 1700000 ticks in ~92 sec
And query disappears from the flame graph
bors [Fri, 2 Mar 2018 18:43:11 +0000 (18:43 +0000)]
Auto merge of #5095 - tdbgamer:master, r=matklad
Issue #5087
* remove Workspace::current_manifest
* remove incorrect logging
* move empty check to Packages::into_package_id_specs
* add test case mentioned in issue
bors [Thu, 1 Mar 2018 21:49:10 +0000 (21:49 +0000)]
Auto merge of #5100 - alexcrichton:better-dep-ordering, r=matklad
Improve Cargo's scheduling of builds
Historically Cargo has been pretty naive about scheduling builds, basically just
greedily scheduling as much work as possible. As pointed out in #5014, however,
this isn't guaranteed to always have the best results. If we've got a very deep
dependency tree that would otherwise fill up our CPUs Cargo should ideally
schedule these dependencies first. That way when we reach higher up in the
dependency tree we should have more work available to fill in the cracks if
there's spare cpus.
Alex Crichton [Thu, 1 Mar 2018 06:04:54 +0000 (22:04 -0800)]
Improve Cargo's scheduling of builds
Historically Cargo has been pretty naive about scheduling builds, basically just
greedily scheduling as much work as possible. As pointed out in #5014, however,
this isn't guaranteed to always have the best results. If we've got a very deep
dependency tree that would otherwise fill up our CPUs Cargo should ideally
schedule these dependencies first. That way when we reach higher up in the
dependency tree we should have more work available to fill in the cracks if
there's spare cpus.
bors [Thu, 1 Mar 2018 21:27:17 +0000 (21:27 +0000)]
Auto merge of #5000 - Eh2406:i4347, r=alexcrichton
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?
bors [Thu, 1 Mar 2018 19:48:18 +0000 (19:48 +0000)]
Auto merge of #5103 - alexcrichton:no-hamcrest, r=matklad
Drop outdated hamcrest dependency
This hasn't been updated in awhile and in general we've been barely using it.
This drops the outdated dependency and vendors a small amount of the
functionality that it provided. I think eventually we'll want to transition away
from this method of assertions but I wanted to get this piece in to avoid too
much churn in one commit.
Alex Crichton [Thu, 1 Mar 2018 18:14:17 +0000 (10:14 -0800)]
Drop outdated hamcrest dependency
This hasn't been updated in awhile and in general we've been barely using it.
This drops the outdated dependency and vendors a small amount of the
functionality that it provided. I think eventually we'll want to transition away
from this method of assertions but I wanted to get this piece in to avoid too
much churn in one commit.
Eh2406 [Tue, 27 Feb 2018 21:42:39 +0000 (16:42 -0500)]
fix the todo's
needs a test where we have an activation_error the then try activate something that dose not work and backtrack to where we had the activation_error then:
- Hit fast backtracking that go past the crate with the missing features
- Or give a bad error message that does not mention the activation_error.
The test will pass, but there is code that is not yet justified by tests
bors [Wed, 28 Feb 2018 15:20:30 +0000 (15:20 +0000)]
Auto merge of #5097 - matklad:end-of-tls-saga-hopefully, r=alexcrichton
Revert "Warn Windows 7 users about old TLS"
We now have upgraded libgit2 version, so Cargo would use TLS 1.2
on windows unconditionally. Note that even *unpatched* windows 7
supports TLS 1.2.
@retep998, you've originally written that
>TLS 1.2 support for Windows 7 still requires a rather recent patch and so even if we do fix that, we should still keep this error message because some people use Windows 7 with automatic updates disabled.
However, it looks like Windows 7 **does** support TLS 1.2 out of the box, and the update is required to enable the use of TLS 1.2 by default:
Alex Crichton [Tue, 27 Feb 2018 15:50:05 +0000 (07:50 -0800)]
Respect lock files in crates.io crates
Currently Cargo doesn't publish lock files in crates.io crates but we'll
eventually be doing so, so this changes Cargo to recognize `Cargo.lock` when
it's published to crates.io as use it as the basis for resolution during `cargo
install`.
bors [Tue, 27 Feb 2018 04:24:19 +0000 (04:24 +0000)]
Auto merge of #5059 - tobywhughes:master, r=alexcrichton
Clean with --verbose now prints path of what is being removed.
Added verbose output for the clean command. Simply takes whatever is passed into the rm_rf() function and outputs "Removing /whatever/the/path/to/remove/is"
[Issue this is being used for](https://github.com/rust-lang/cargo/issues/5056)
It makes `cargo --version` to print the corresponding Rust version (with possibly cargo-specific patch number), while keeping the library version the same as today.
On the one hand, this is horrible. On the other hand, it seems to do the job? In the long term, it would be cool skip one version bump for the library, so that `0.x` corresponds to `1.x`.
cc @rust-lang/cargo
I am not sure that this is good idea, the implementation certainly feels horrible :)
bors [Mon, 26 Feb 2018 19:59:27 +0000 (19:59 +0000)]
Auto merge of #5069 - matklad:win7-y-u-no-tls, r=alexcrichton
Warn Windows 7 users about old TLS
An eyepatch for https://github.com/rust-lang/cargo/issues/5066.
@retep998 what would the best way to check for windows 7 specifically? Currently I use just `#[cfg(windows)]`, which might give false positives on 8 and 10.
> ```toml
> # This is a string description of the license for this package. Currently
> # crates.io will validate the license provided against a whitelist of known
> # license identifiers from http://spdx.org/licenses/. Multiple licenses can be
> # separated with a `/`.
> license = "..."
> ```
bors [Sat, 24 Feb 2018 19:34:52 +0000 (19:34 +0000)]
Auto merge of #5061 - ehuss:git-error-auth, r=alexcrichton
Display git errors during authentication.
Certain git errors during authentication were being converted to internal errors which meant that they are only seen if you pass `--verbose`. This may not be obvious, and many of these messages are helpful for diagnosing git errors. This change makes these errors always be displayed.
Fixes #5035.
Note: Some of the git errors are currently unhelpful. Once Cargo has updated git2-rs to include alexcrichton/git2-rs#298, these errors will improve. (@alexcrichton, I can make a PR to update Cargo for the changes in git2 if you'd like).
I'm uncertain if this is a good solution, since the error messages in some cases are a little verbose (such as showing `class=...`). Here is a sample of what some of the messages look like:
<details><summary>Error Message Examples</summary>
<p>
Example of the git message shown below the "attempted yadda yadda" message.
Scenario | Message
---------|--------
No ssh-agent, multiple usernames | `error authenticating: ; class=Ssh (23)`
| | †`error authenticating: no auth sock variable; class=Ssh (23)`
No ssh-agent, one username | `an unknown git error occurred`
| | †`error authenticating: no auth sock variable; class=Ssh (23)`
Incorrect ssh-agent setup | `error authenticating: failed connecting with agent; class=Ssh (23)`
ssh-agent no keys, one username | `an unknown git error occurred`
| | †`failed to acquire username/password from local configuration`
ssh-agent no keys, multiple usernames | `error authenticating: ; class=Ssh (23)`
| | †`no authentication available`
auth success, bad path | `fatal: '/path/to/repo/' does not appear to be a git repository; class=Ssh (23); code=Eof (-20)`
| | ‡`ERROR: Repository not found.; class=Ssh (23); code=Eof (-20)`
bad username | `an unknown git error occurred`
| | †`failed to acquire username/password from local configuration`
| | ‡`error authenticating: Username/PublicKey combination invalid; class=Ssh (23)`
† - Messages once git2-rs is updated.
‡ - Github message
Eh2406 [Thu, 15 Feb 2018 22:36:30 +0000 (17:36 -0500)]
make RemainingCandidates::next peekable.
`candidates.next` always came with a `candidates.clone().next(prev_active).is_ok` so lets just make that part of `next`. no `clone` needed.
bors [Wed, 21 Feb 2018 19:56:27 +0000 (19:56 +0000)]
Auto merge of #5063 - Eh2406:TestssuiteV3, r=matklad
Reorganize integration tests as one crate with many modules. Issue #4867. Rebased V3
This is an automatic rebase of @rochamatcomp's work in #5022, as requested in [#5038](https://github.com/rust-lang/cargo/pull/5038#issuecomment-365200227).
I take no credit for the changes; I just wanted faster test for my work. :-)
bors [Mon, 19 Feb 2018 21:39:17 +0000 (21:39 +0000)]
Auto merge of #5051 - cardoe:fix-doc-instructions, r=matklad
update contributing to show how to build the docs
The contributing guide referenced a script that was deleted in 1271bb4de0c0 so it wasn't possible to follow the contributing guide
successfully prior to contributing doc improvements.
Here three crates will be imported but they'll be made available to the Rust
source code via the names `foo` (crates.io), `bar` (the custom registry), and
`baz` (the git dependency). The *package* name, however, will be `foo` for all
of them. In other words the git repository here would be searched for a crate
called `foo`. For example:
* Enable depending on the same named crate from different registries
* Allow depending on multiple versions of a crate from one registry
* Removing the need for `extern crate foo as bar` syntactically in Rust source
Currently I don't think we're ready to stabilize this so it's just a nightly
feature, but I'm hoping we can continue to iterate on it!
Doug Goldstein [Sun, 18 Feb 2018 04:41:32 +0000 (22:41 -0600)]
update contributing to show how to build the docs
The contributing guide referenced a script that was deleted in 1271bb4de0c0 so it wasn't possible to follow the contributing guide
successfully prior to contributing doc improvements.
bors [Wed, 14 Feb 2018 16:52:47 +0000 (16:52 +0000)]
Auto merge of #5037 - Eh2406:conflict_tracking, r=alexcrichton
Conflict tracking
This is an alternative implementation of #4834. This is slower but hopefully more flexible and clearer. The idea is to keep a list of `PackageId`'s that have caused us to skip a `Candidate`. Then we can use the list when we are backtracking if any items in our list have not been activated then we will have new `Candidate`'s to try so we should stop backtracking. Or to say that another way; We can continue backtracking as long as all the items in our list is still activated.
Next this new framework was used to make the error messages more focused. We only need to list the versions that conflict, as opposed to all previously activated versions.
Why is this more flexible?
1. It is not limited to conflicts within the same package. If `RemainingCandidates.next` skips something because of a links attribute, that is easy to record, just add the `PackageId` to the set `conflicting_prev_active`.
2. Arbitrary things can add conflicts to the backtracking. If we fail to activate because some dependency needs a feature that does not exist, that is easy to record, just add the `PackageId` to the set `conflicting_activations`.
3. All things that could cause use to fail will be in the error messages, as the error messages loop over the set.
4. With a simple extension, replacing the `HashSet` with a `HashMap<_, Reason>`, we can customize the error messages to show the nature of the conflict.
@alexcrichton, @aidanhs, Does the logic look right? Does this seem clearer to you?