Alex Crichton [Wed, 29 Nov 2017 01:44:25 +0000 (17:44 -0800)]
Fix the lockfile-compat test
The newest version of `tar` tweaks the checksum here slightly as the tarball is
slightly different, so this just updates the test to pull the checksum from the
publication rather than hardcoding it.
bors [Sat, 18 Nov 2017 00:03:28 +0000 (00:03 +0000)]
Auto merge of #4568 - Metaswitch:alt-registry-publish, r=withoutboats
Add support for publish to optionally take the index that can be used
This form part of alternative-registries RFC-2141, it allows crates to optionally specify which registries the crate can be be published to.
@carols10cents, one thing that I am unsure about is if there is a plan for publish to still provide index, or for registry to be provided instead. I thought that your general view was that we should move away from the index file. If we do need to map allowed registries to the index then there will be a small amount of extra work required once #4506 is merged.
@withoutboats, happy for this to be merged into your branch if you want, the main reason I did not base it on your branch was due to tests not working on there yet.
bors [Sun, 12 Nov 2017 19:13:19 +0000 (19:13 +0000)]
Auto merge of #4714 - Mark-Simulacrum:frozen-freezes, r=alexcrichton
Do not update semantically equivalent lockfiles with --frozen/--locked.
A previous patch in #4684 attempted to fix this, but didn't work for the
case where the [root] crate wasn't the first crate in the sorted package
array.
cc @matklad -- fixes a problem noted in https://github.com/rust-lang/cargo/pull/4684#discussion_r147824900 which appears to have gone unfixed
r? @alexcrichton
Beta backport will be posted as soon as this is reviewed. Merges cleanly.
Mark Simulacrum [Sun, 12 Nov 2017 17:57:05 +0000 (10:57 -0700)]
Do not update semantically equivalent lockfiles with --frozen/--locked.
A previous patch in #4684 attempted to fix this, but didn't work for the
case where the [root] crate wasn't the first crate in the sorted package
array.
bors [Thu, 9 Nov 2017 07:39:03 +0000 (07:39 +0000)]
Auto merge of #4705 - Metaswitch:fix-yank-help, r=matklad
Stop yank -h from panicking on nightly
Increase the gap between the registry option and the description so that the help is parsed correctly. I have also checked the code for the other binaries to ensure that they don't suffer from the same issue.
bors [Tue, 7 Nov 2017 18:12:25 +0000 (18:12 +0000)]
Auto merge of #4701 - mathstuf:update-lockfile-color-reflects-change, r=alexcrichton
cargo_generate_lockfile: use color to also indicate the change
In English, `Updating` and `Removing` are the same length and scanning
the list for changes is hard. Use color to help indicate the kind of
change that is occurring.
Ben Boeckel [Tue, 7 Nov 2017 16:56:38 +0000 (11:56 -0500)]
cargo_generate_lockfile: use color to also indicate the change
In English, `Updating` and `Removing` are the same length and scanning
the list for changes is hard. Use color to help indicate the kind of
change that is occurring.
bors [Mon, 6 Nov 2017 18:35:46 +0000 (18:35 +0000)]
Auto merge of #4646 - alexcrichton:progress, r=matklad
Add a number of progress indicators to Cargo
This commit is an attempt to stem the tide of "cargo is stuck updating the
registry" issues by giving a better indication as to what's happening in
long-running steps. The primary addition here is a `Progress` helper module
which prints and manages a progress bar for long-running operations like git
fetches, git checkouts, HTTP downloads, etc.
The second addition here is to print out when we've been stuck in resolve for
some time. We never really have a progress indicator for crate graph resolution
nor do we know when we're done updating sources. Instead we make a naive
assumption that when you've spent 0.5s in the resolution loop itself (not
updating deps) you're probably done updating dependencies and on to acutal
resolution. This will print out `Resolving crate graph...` and help inform that
Cargo is indeed not stuck looking at the registry, but rather it's churning away
in resolution.
Alex Crichton [Mon, 16 Oct 2017 14:57:38 +0000 (07:57 -0700)]
Add a number of progress indicators to Cargo
This commit is an attempt to stem the tide of "cargo is stuck updating the
registry" issues by giving a better indication as to what's happening in
long-running steps. The primary addition here is a `Progress` helper module
which prints and manages a progress bar for long-running operations like git
fetches, git checkouts, HTTP downloads, etc.
The second addition here is to print out when we've been stuck in resolve for
some time. We never really have a progress indicator for crate graph resolution
nor do we know when we're done updating sources. Instead we make a naive
assumption that when you've spent 0.5s in the resolution loop itself (not
updating deps) you're probably done updating dependencies and on to acutal
resolution. This will print out `Resolving crate graph...` and help inform that
Cargo is indeed not stuck looking at the registry, but rather it's churning away
in resolution.
bors [Wed, 1 Nov 2017 15:24:12 +0000 (15:24 +0000)]
Auto merge of #4680 - Metaswitch:registry-login, r=alexcrichton
Support login tokens for multiple registries
This pull request builds on #4206 to support login using the the registry from alternate registries (RFC 2141). This includes the following changes:
- allow credentials to be stored based on the registry
- allow passing the registry to run cargo commands against using --registry
Note that this does not include a feature gate on the use of --registry as the publish code blocks publish if we use any features. @alexcrichton, are you happy with this approach, or is there a way that you would recommend this should be relaxed for testing purposes?
bors [Tue, 31 Oct 2017 22:13:57 +0000 (22:13 +0000)]
Auto merge of #4692 - nossralf:add-rustfmt-config, r=matklad
Add rustfmt.toml with formatting disabled
Currently, Cargo does not use rustfmt for its source code. By adding a rustfmt.toml that simply disables all formatting rules, editors which use rustfmt by default for all Rust code will do the right thing and leave the source code unchanged,.
This makes life a little bit easier for developers who no longer need to explicitly disable automatic rustfmt formatting when working on Cargo to avoid code unrelated to a change being reformatted.
Fredrik Larsson [Tue, 31 Oct 2017 21:31:02 +0000 (22:31 +0100)]
Add rustfmt.toml with formatting disabled
Currently, Cargo does not use rustfmt for its source code. By adding a
rustfmt.toml that simply disables all formatting rules, editors which
use rustfmt by default for all Rust code will do the right thing and
leave the source code unchanged.
bors [Tue, 31 Oct 2017 16:49:55 +0000 (16:49 +0000)]
Auto merge of #4683 - djc:requirements, r=alexcrichton
Introduce Requirements struct to clarify code
`cargo::core::resolver::build_requirements()` previously, in this order:
* Defined local variables to track state
* Called a function to mutate the local variables
* Defined the aforementioned function
* Returned two out of three local variables as a tuple
This PR changes the code so that this is a recast as a struct (appropriately called `Requirements`), which is mutated in a more fine-grained way by its methods and acts as the return type for `build_requirements()`. To me, this seems a lot easier to understand.
This work was done in the context of #1286, but I figured it was easier to start landing some of the refactoring to avoid bitrot and get early (well, earlier) feedback.
bors [Tue, 31 Oct 2017 14:14:46 +0000 (14:14 +0000)]
Auto merge of #4684 - matklad:lazy-update, r=alexcrichton
Don't update lockfiles from previous Cargo versions if `--locked` is passed
Recently, we've stopped outputting `[root]` section to Cargo.lock files. The problem with this is that somebody might want to have a Cargo.lock file with a `[root]` section for compatibility with older Cargos, but at the same time use newer Cargo to build the crate. In this case, newer Cargo would remove `[root]` from the lockfile. Such updating of the lockfiles to the latest versions is a reasonable behavior, but it might be useful to be able to override it with `--locked` flag.
bors [Tue, 31 Oct 2017 00:48:46 +0000 (00:48 +0000)]
Auto merge of #4676 - mgeisler:ci-caching, r=alexcrichton
Explain why caching is only done on $HOME/.cargo/bin/ in Travis
After having experimented with the Travis and AppVeyor caches, I concluded that they don't really help here: they're large and take a very long time to both download when the build starts and upload after it is finished.
bors [Mon, 30 Oct 2017 18:09:49 +0000 (18:09 +0000)]
Auto merge of #4607 - sunjay:patcherror, r=alexcrichton
Improving the error message for when a patched dependency does not resolve to anything
Hi,
I just spent a long time debugging what this error message means and so I thought I would try to help improve it. Could someone who knows the codebase well look at this and see if this error message even makes sense here. I know this is the information I would have needed, but the error may occur in other cases where this message doesn't make sense. I'm open to any suggestions that would help make it more clear and maybe point people to where they should look for more information.
The specific problem that I ran into occurred when I was trying to upgrade the `rustfmt` submodule in the rust codebase. The `rustfmt-nightly` dependency changed version numbers and this conflicted with what was in the `Cargo.lock` file. After some detective work I was able to find the [documentation on `[patch]`](http://doc.crates.io/manifest.html#the-patch-section) which I had never read before and the following relevant paragraphs from [some other documentation](http://doc.crates.io/specifying-dependencies.html#testing-a-bugfix):
> Next up we need to ensure that our lock file is updated to use this new version of uuid so our project uses the locally checked out copy instead of one from crates.io. The way [patch] works is that it'll load the dependency at ../path/to/uuid and then whenever crates.io is queried for versions of uuid it'll also return the local version.
>
> This means that the version number of the local checkout is significant and will affect whether the patch is used. Our manifest declared uuid = "1.0" which means we'll only resolve to >= 1.0.0, < 2.0.0, and Cargo's greedy resolution algorithm also means that we'll resolve to the maximum version within that range. Typically this doesn't matter as the version of the git repository will already be greater or match the maximum version published on crates.io, but it's important to keep this in mind!
If it was not for the person who wrote those docs, I would not have known what to do here!
bors [Mon, 30 Oct 2017 16:50:15 +0000 (16:50 +0000)]
Auto merge of #4592 - ehuss:check_test, r=alexcrichton
Add unit test checking to `cargo check`
This is an extension of PR #4039, fixing #3431, #4003, #4059, #4330. The fixes for #4059 can potentially be separated into a separate PR, though there may be some overlap.
The general gist of the changes:
- Add `--profile test` flag to `cargo check` that will enable checking of unit tests.
- `--tests` will implicitly enable checking of unit tests within the lib (checks the same targets as `cargo test`). This affects the `check`, `test`, and `build` commands.
- `--benches` behaves similarly by using the same targets as `cargo bench`.
- Fix erroneously linking tests when run with `--test`.
There is one thing I did not do because I wanted more feedback on what others think the expected behavior should be. What should the behavior of `--all-targets` be? This patch does not (yet) make any changes to its behavior. My initial thinking is that it should *add* a target of `--lib --bins --profile test`, but that essentially means the lib and bin targets will be checked twice (and thus any errors/warnings outside of `#[cfg(test)]` will appear twice, which may be confusing, and generally take twice as long to run). I can add that, but I think it would require adding a new `All` variant to `CompileFilter` so that the code in `generate_targets` can detect this scenario. I wanted feedback before making a more extensive change like that. The downside of not adding it is that `--all-targets` will ignore unit tests (if you don't specify `--profile test`).
bors [Fri, 27 Oct 2017 14:02:41 +0000 (14:02 +0000)]
Auto merge of #4665 - lukaslueg:issue4327, r=matklad
Discover vcs in new-cmd only if --vcs not set
If a commandline-argument is given, it takes precedence
over the config and existing vcs. Avoid trying to discover
existing repositories in that case, saving use from
shelling out to `hg`. Fixes #4327
Lukas Lueg [Fri, 27 Oct 2017 13:00:23 +0000 (15:00 +0200)]
Discover vcs in new-cmd only if --vcs not set
If a commandline-argument is given, it takes precedence
over the config and existing vcs. Avoid trying to discover
existing repositories in that case, saving use from
shelling out to `hg`. Fixes #4327
bors [Thu, 26 Oct 2017 10:44:49 +0000 (10:44 +0000)]
Auto merge of #4650 - main--:patch-1, r=matklad
Document that cargo test --release uses profile.bench
It certainly makes sense but it's still surprising behavior when the docs clearly state `cargo bench` = `profile.bench`, `cargo test` = `profile.test`. Had to dive into the code to figure this out.
bors [Thu, 26 Oct 2017 07:35:44 +0000 (07:35 +0000)]
Auto merge of #4634 - kivikakk:cargo-env-prevails, r=matklad
Use argv[0] for cargo_exe so we don't rely on /proc on Linux
This is a proposed solution to #4450. I'm not at all wedded to the idea or the code, though, so feel free to shoot it down with abandon if this isn't something that'd work out or that you like.
In short, we use the existing `CARGO_ENV` (`"CARGO"`) if present, and only if not do we attempt to perform a lookup with `env::current_exe()` ourselves. This means users without access to `current_exe` (such as Linux without `procfs` mounted) can supply the `CARGO` env var themselves for external commands to use.
My concern here is: what if maybe we intentionally switch cargo binaries and didn't intend for this to happen? Could this ever happen outside a test environment? This kind-of-sorta-happened by accident in the test suite, necessitating the explicit removal of `CARGO_ENV` from the subprocess environment, because the actual cargo executing the test suite propagated its own path into the test subprocess!
/cc @alexcrichton as the originator of the idea of `CARGO_ENV`
bors [Wed, 25 Oct 2017 14:29:13 +0000 (14:29 +0000)]
Auto merge of #4627 - integer32llc:document-libs-and-bins, r=matklad
Document the lib if a lib and bin have the same name
Fixes #4341, as discussed in that issue.
- Removes the check that bailed if there was a bin and lib with the
same name
- Exclude bins with the same name as libs from the proposed targets to
build when compiling docs
- Adjust tests to expect this behavior
Document the lib if a lib and bin have the same name
Fixes #4341.
- Removes the check that bailed if there was a bin and lib with the
same name
- Exclude bins with the same name as libs from the proposed targets to
build when compiling docs
- Adjust tests to expect this behavior
bors [Wed, 25 Oct 2017 06:42:27 +0000 (06:42 +0000)]
Auto merge of #4649 - jongiddy:gitignore-newline, r=alexcrichton
Add a newline before appended VCS ignore lines
The `cargo init` command appends to `.gitignore` or `.hgignore` without checking if the last line of the existing file ends with a newline.
This change will insert a newline before the appended lines. If the last line has no newline, this will ensure the lines are kept separated. If the newline is present, this will insert a blank line. Both Git and Mercurial ignore blank lines in these files.
bors [Wed, 25 Oct 2017 00:11:50 +0000 (00:11 +0000)]
Auto merge of #4659 - integer32llc:pin-nightly, r=alexcrichton
try pinning to a nightly of two weeks ago
This passed CI [over here](https://github.com/rust-lang/cargo/pull/4658) and should get the 32-bit windows cross compiling tests passing until someone figures out why rustc is broken for that purpose
projects / cargo.git / log