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
bors [Thu, 19 Oct 2017 07:58:19 +0000 (07:58 +0000)]
Auto merge of #4623 - alexcrichton:remove-lock, r=matklad
Delete Cargo.lock from this repo
There's now a lock file upstream in rust-lang/rust so the one here isn't
actually used, and otherwise this crate is used as a dependency so the lock file
isn't respected anyway!
Alex Crichton [Sun, 10 Sep 2017 16:38:29 +0000 (09:38 -0700)]
Delete Cargo.lock from this repo
There's now a lock file upstream in rust-lang/rust so the one here isn't
actually used, and otherwise this crate is used as a dependency so the lock file
isn't respected anyway!
bors [Wed, 18 Oct 2017 12:50:42 +0000 (12:50 +0000)]
Auto merge of #4633 - kivikakk:readme-file, r=carols10cents
transmit: send README filename as well as content
This is required to solve https://github.com/rust-lang/crates.io/issues/995; we currently only send the README content, but not the name of the README itself, so it's not possible to determine how we should render it.
I've confirmed the existing crates.io server silently ignores the new field, so this should be safe to roll out whenever.