Auto merge of #3914 - jwilm:specifying-dependencies-replace-note, r=alexcrichton
Add note about Cargo.lock behavior with [replace]
The Cargo.lock behavior when using [replace] can be misleading if one
does not expect multiple versions of the crate to be included. This note
is intended to assure users that this behavior is expected, and it
suggests a way to verify their `[replace]` override is preferred.
I ran into this issue and ended up bugging @alexcrichton about it. Hopefully including this will reduce the support burden on cargo devs :smile:.
Joe Wilm [Mon, 10 Apr 2017 20:24:31 +0000 (13:24 -0700)]
Add note about Cargo.lock behavior with [replace]
The Cargo.lock behavior when using [replace] can be misleading if one
does not expect multiple versions of the crate to be included. This note
is intended to assure users that this behavior is expected, and it
suggests a way to verify their `[replace]` override is preferred.
Auto merge of #3854 - tee-too:fix-3499, r=alexcrichton
Add `[target.'cfg(...)']` syntax for rustc(doc)flags in .cargo/config
Allow to use the Rust `cfg(...)` syntax to configure rust(doc)flags.
The flags are concatenated when a build matches several `cfg`, or
several `cfg` and a $triple.
Add `[target.'cfg(...)']` syntax for rustc(doc)flags in .cargo/config
Allow to use the Rust `cfg(...)` syntax to configure rust(doc)flags.
The flags are concatenated when a build matches several `cfg`, or
several `cfg` and a $triple.
Auto merge of #3893 - nrc:config-values, r=alexcrichton
Allow a client to override values in a config
The use case here is that the RLS wants to set a project's `target-dir`, but can't do this using a config file (since the user might have their own, and it's a bit hacky) or via an environment variable (because there might be multiple instances of Cargo running on different directories in different threads.
ISTM that the best way to accomplish this is to allow the RLS to override values in the config before we make a workspace from it. However, since the config uses a `LazyCell` for the config values, this is not very nice (if something tries to read a config value before we set them, then there will be an error when we try to set them). However, this meets our needs and is pretty low impact, so it seems like the best solution for now. I'm open to other ideas though.
Auto merge of #3842 - pwoolcoc:add-pijul-vcs-support, r=alexcrichton
Add Pijul support to Cargo
[Pijul](https://pijul.org) is a version control system written in Rust. This commit adds the ability to create a cargo project using pijul as the vcs for the project.
To use it, run `cargo new my-awesome-project --vcs=pijul`
Paul Woolcock [Fri, 31 Mar 2017 15:35:58 +0000 (11:35 -0400)]
Add Pijul support to cargo
[Pijul](https://pijul.org) is a version control system written in Rust. This commit adds the ability to create a cargo project using pijul as the vcs for the project.
To use it, run `cargo new my-awesome-project --vcs=pijul`
bors [Fri, 31 Mar 2017 15:50:19 +0000 (15:50 +0000)]
Auto merge of #3878 - ehiggs:revert-template-until-after-rfc, r=alexcrichton
Revert template until after rfc
As discussed in #3860, templates was merged without going through the RFC process. @ssokolow has raised some useful comments which need to be settled before the template system can be put back in.
bors [Thu, 30 Mar 2017 15:25:03 +0000 (15:25 +0000)]
Auto merge of #3879 - jbendig:issue_3867, r=alexcrichton
Fix `cargo run` panic when required-features not satisfied
This PR fixes #3867 which is made up of two parts.
The first part involves `cargo run` triggering an assertion after compiling. This is triggered by the single binary selected for compilation being filtered out when required-features is specified and said features are not enabled. The cleanest approach to me involves just sticking a flag into `CompileFilter::Everything`. The flag then triggers the already existing error message when required-features is not satisfied. I think this works best because it localizes what is really a `cargo run` quirk without requiring any boilerplate or duplicate code.
The second part shows `cargo run` bailing when two binaries exist, both with required-features, but only one is resolved to be compiled due to default features. I feel like the current approach is correct because it's consistent with what normally happens when there are multiple binaries. I'm open to changing this, but for now, I've added a test to enforce this behavior.
cc @BenWiederhake: I took a quick peek at your branch to fix #3112 and I noticed that it probably won't merge cleanly with this PR. Just an FYI in case it makes sense to have this merged.
bors [Thu, 23 Mar 2017 23:26:55 +0000 (23:26 +0000)]
Auto merge of #3857 - antonlarin:rebuild-on-env-change, r=alexcrichton
Include package props with corresponding env vars into target metadata
Previously, when changing package properties with corresponding environment variables (such as authors, which has CARGO_PKG_AUTHORS), it didn't invalidate the build, even though there could have been a dependency on such variables in the source code.
This commit includes 3 such properties: authors list, description and homepage in the target metadata.
I've added a test only for description change, can add more if necessary.
Fixes #3696.
bors [Thu, 23 Mar 2017 21:56:53 +0000 (21:56 +0000)]
Auto merge of #3837 - alexcrichton:workspace-exlucde, r=brson
Add a workspace.exclude key
This commit adds a new key to the `Cargo.toml` manifest, `workspace.exclude`.
This new key is a list of strings which is an array of directories that are
excluded from the workspace explicitly. This is intended for use cases such as
vendoring where path dependencies into a vendored directory don't want to pull
in the workspace dependencies.
There's a number of use cases mentioned on #3192 which I believe should all be
covered with this strategy. At a bare minimum it should suffice to `exclude`
every directory and then just explicitly whitelist crates through `members`
through inclusion, and that should give precise control over the structure of a
workspace.
Anton Larin [Thu, 23 Mar 2017 14:26:40 +0000 (17:26 +0300)]
Include package props with env vars into target metadata
Previously, when changing package properties with corresponding
environment variables (such as authors, which has CARGO_PKG_AUTHORS),
it didn't invalidate the build, even though there could have been
a dependency on such variables in the source code.
This commit includes such properties (there are 3 of them in total:
authors, description and homepage) in the target metadata.
bors [Sat, 18 Mar 2017 13:01:54 +0000 (13:01 +0000)]
Auto merge of #3843 - alexcrichton:fix-override-default-features, r=matklad
Fix overriding mixing with default features
Previously Cargo had a bug where if a crate *without* a default feature was
overridden with one that did indeed have a default feature then the default may
not end up getting activated by accident. The fix was to avoid returning too
quickly hen activating dependencies until after we've inspected and learned
about replacements.
Alex Crichton [Fri, 17 Mar 2017 23:12:11 +0000 (16:12 -0700)]
Fix overriding mixing with default features
Previously Cargo had a bug where if a crate *without* a default feature was
overridden with one that did indeed have a default feature then the default may
not end up getting activated by accident. The fix was to avoid returning too
quickly hen activating dependencies until after we've inspected and learned
about replacements.
Alex Crichton [Thu, 16 Mar 2017 21:50:23 +0000 (14:50 -0700)]
Add a workspace.exclude key
This commit adds a new key to the `Cargo.toml` manifest, `workspace.exclude`.
This new key is a list of strings which is an array of directories that are
excluded from the workspace explicitly. This is intended for use cases such as
vendoring where path dependencies into a vendored directory don't want to pull
in the workspace dependencies.
There's a number of use cases mentioned on #3192 which I believe should all be
covered with this strategy. At a bare minimum it should suffice to `exclude`
every directory and then just explicitly whitelist crates through `members`
through inclusion, and that should give precise control over the structure of a
workspace.
bors [Mon, 13 Mar 2017 22:21:16 +0000 (22:21 +0000)]
Auto merge of #3827 - alexcrichton:warnings-v2, r=matklad
Cap lints for upstream deps with `-vv`
Previously with `-vv` Cargo didn't pass `--cap-lints` at all, but with upstream
dependencies we still want to pass at least `--cap-lints warn` to make sure that
they're all still compiling.
Alex Crichton [Mon, 13 Mar 2017 17:15:36 +0000 (10:15 -0700)]
Cap lints for upstream deps with `-vv`
Previously with `-vv` Cargo didn't pass `--cap-lints` at all, but with upstream
dependencies we still want to pass at least `--cap-lints warn` to make sure that
they're all still compiling.
bors [Wed, 8 Mar 2017 19:21:14 +0000 (19:21 +0000)]
Auto merge of #3794 - alexcrichton:better-errors, r=matklad
Improve TOML decoding error messages
Unfortunately while `#[serde(untagged)]` is precisely what we want in terms of
semantics it leaves a little to be desired in terms of error messages. This
commit updates to remove the usage of that attribute in favor of implementing
`Deserialize` directly, which is quite simple in these few cases.
Alex Crichton [Fri, 3 Mar 2017 16:12:12 +0000 (08:12 -0800)]
Improve TOML decoding error messages
Unfortunately while `#[serde(untagged)]` is precisely what we want in terms of
semantics it leaves a little to be desired in terms of error messages. This
commit updates to remove the usage of that attribute in favor of implementing
`Deserialize` directly, which is quite simple in these few cases.
bors [Wed, 8 Mar 2017 00:00:34 +0000 (00:00 +0000)]
Auto merge of #3789 - vojtechkral:cargo_env, r=alexcrichton
Tell subprocesses the path to self in an env variable #3778
I'm just setting the env var on the process itself, letting subprocesses inherit that, as it's easier than setting for each subprocess individually. I'm not entirely sure this is the right spot though.
Also, I should probably document this somewhere - what would be the best place?
bors [Tue, 7 Mar 2017 15:24:52 +0000 (15:24 +0000)]
Auto merge of #3369 - joshtriplett:cargo-install-only-required-dependencies, r=alexcrichton
cargo fails if it can't find optional dependencies, even if corresponding feature not enabled
I have a directory registry containing all the crate sources needed to build an application crate (for instance, ripgrep), and a `$CARGO_HOME/config` file that looks like this:
When I attempt to build ripgrep via "cargo install ripgrep" from that directory registry, I get this error:
```
error: failed to compile `ripgrep v0.3.1`, intermediate artifacts can be found at `/tmp/cargo-install.rmKApOw9BwAL`
Caused by:
no matching package named `simd` found (required by `bytecount`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: ^0.1.1
```
The directory registry indeed does not contain "simd"; however, bytecount doesn't require simd. It has an optional dependency on simd, and nothing enables the feature that requires that dependency.
Placing the simd crate sources into the directory registry allows ripgrep to build; the resulting build does not actually build the simd crate.
I can reproduce this by just trying to build the "bytecount" crate directly, using the same `$CARGO_HOME`:
```
error: no matching package named `simd` found (required by `bytecount`)
location searched: registry https://github.com/rust-lang/crates.io-index
version required: = 0.1.1
```
(Incidentally, that "version required" seems wrong: bytecount has an optional dependency on simd `^0.1.1`, not `=0.1.1`.)
However, this doesn't seem consistent with other crates in the same dependency tree. For instance, ripgrep also depends on clap, and clap has an optional dependency on yaml-rust, yet cargo does not complain about the missing yaml-rust.
I'd *guess* that the difference occurs because ripgrep has an optional feature `simd-accel` that depends on `bytecount/simd-accel`, so cargo wants to compute what packages it needs for that case too, even when building without that feature. (Similar to #3233.)
However, this makes it impossible to build a package while installing only the packaged dependencies for the enabled features. Could `cargo install` ignore any dependencies not actually required by the enabled feature? (That behavior would make no sense for "cargo build", which builds a Cargo.lock file that should remain consistent regardless of enabled features, but it makes sense for "cargo install cratename", which doesn't build a Cargo.lock file.)
bors [Mon, 6 Mar 2017 20:42:29 +0000 (20:42 +0000)]
Auto merge of #3795 - jryans:template-year, r=alexcrichton
Add year to project template variables
This adds the current year as a `year` variable for project templates. Some license files / headers include the year, so this should make it easier to include those in a template.
Josh Triplett [Thu, 2 Mar 2017 02:19:43 +0000 (18:19 -0800)]
In "cargo install" directly from registry, don't require optional dependencies
When building with a directory registry that contains only the subset of
crates required to build an application crate, cargo fails if that
subset doesn't include optional dependencies pulled in for every
possible feature of the root crate, even when the install doesn't enable
those features. This prevents Linux distributions from building with
a minimal set of dependencies (omitting, for instance, packages for
unstable/nightly features).
Introduce a new workspace flag "require_optional_deps", disabled for
install and enabled for everything else. Skip the initial
Method::Everything resolve in this case, and modify
resolve_with_previous to support running a Method::Required resolve
without a previous resolution.
This also skips adding path overrides, as those won't make sense (and
won't work) for an install directly from a registry.
Introduce a set of tests for "cargo install" directly from a directory
registry.
It looks like this was changed as part of #3004 ([removed](https://github.com/rust-lang/cargo/commit/875a8aba7916b63c3c8464008a271f6082e23779#diff-149dd4362a3b0dc13b113762713119dfL477), [added](https://github.com/rust-lang/cargo/commit/875a8aba7916b63c3c8464008a271f6082e23779#diff-149dd4362a3b0dc13b113762713119dfR678)), I'm assuming unintentionally?
The regression has not yet hit the beta channel; `cargo-0.17.0-nightly (0bb8047 2017-02-06)` generates the src/lib.rs I expect.
bors [Fri, 3 Mar 2017 15:40:30 +0000 (15:40 +0000)]
Auto merge of #3791 - sunng87:port-handlebars-to-serde, r=alexcrichton
Use serde type system for handlebars
This will help cargo to drop rustc_serialize as dependency (#3682). Handlebars actually supports using serde_json as its type system instead of rustc_serialize. And I'm planning to drop rustc_serialize in future releases.
bors [Thu, 2 Mar 2017 02:10:56 +0000 (02:10 +0000)]
Auto merge of #3785 - joshtriplett:insulate-tests-from-user-env, r=alexcrichton
tests: Insulate from user git environment
Several tests in "cargo test" would fail if the user had any of the Git
environment variables set for name or email address, because those
environment variables would override the tested configuration. Filter
out those environment variables.
Josh Triplett [Wed, 1 Mar 2017 23:50:15 +0000 (15:50 -0800)]
tests: Insulate from user git environment
Several tests in "cargo test" would fail if the user had any of the Git
environment variables set for name or email address, because those
environment variables would override the tested configuration. Filter
out those environment variables.
bors [Wed, 1 Mar 2017 15:05:45 +0000 (15:05 +0000)]
Auto merge of #3721 - alexcrichton:dupe-doctest, r=brson
Fix deps with `cargo test --all` and doctests
This commit fixes `cargo test --all` with the way we ship libraries to `rustdoc
--test`. I'm... not entirely sure what the previous incarnation was doing but
the current organization is to interpret `compilation.libraries` as a mapping
from a package to the list of crates it needs to link to test.
This updates the support in `cargo_rustc/mod.rs` to create the map appropriately
and tweaks the loop in `cargo_test.rs` as well.
Alex Crichton [Thu, 16 Feb 2017 16:04:09 +0000 (08:04 -0800)]
Fix deps with `cargo test --all` and doctests
This commit fixes `cargo test --all` with the way we ship libraries to `rustdoc
--test`. I'm... not entirely sure what the previous incarnation was doing but
the current organization is to interpret `compilation.libraries` as a mapping
from a package to the list of crates it needs to link to test.
This updates the support in `cargo_rustc/mod.rs` to create the map appropriately
and tweaks the loop in `cargo_test.rs` as well.