Auto merge of #3901 - BenWiederhake:all-kinds, r=alexcrichton
Implementation and CLI-support for `--all-$KIND` flags
This implements #3112.
This means all of the following commands are now possible and meaningful:
```
cargo build --all-bins
cargo build --all-tests
cargo test --all-tests
cargo test --all-bins
cargo check --all-bins --all-examples --all-tests --all-benches
```
The commits try to represent the incremental "propagation" of the new feature:
- core functionality (`cargo check --lib` passes)
- CLI suport (`cargo build` passes)
- additional tests (`cargo test` covers new functionality)
Note that `--all` is already reserved to mean "all packages of the workspace", so it can't be used to mean `--all-bins --all-examples --all-tests --all-benches`.
I intend to follow this up by some other PRs, so please do tell me where I could improve.
Auto merge of #3887 - luser:rustc-wrapper, r=alexcrichton
Add support for wrapping cargo's rustc invocations by setting RUSTC_WRAPPER
To use sccache for cargo builds we need a simple way to get sccache into the rustc commandline when cargo invokes rustc. Currently this is only possible by hard-linking or copying the `sccache` binary to be named `rustc` and then either setting `RUSTC` to its path or putting it first in `$PATH`, both of which are sort of clunky and require manual steps even if installing sccache via `cargo install`.
This patch adds support for a `RUSTC_WRAPPER` environment variable which, if set, will simply be inserted as the actual binary for all rustc process execution, with rustc and all other rustc arguments following.
I didn't add any tests for this, I couldn't figure out the right place to put them, and presumably we'd need to build a helper binary of some sort to use as the wrapper. If you've got suggestions for how to do that properly I'd be happy to write tests.
This works well in my local testing:
```
luser@eye7:/build/read-process-memory$ /build/cargo/target/release/cargo clean; time RUSTC_WRAPPER=/build/sccache2/target/release/sccache RUSTC=/home/luser/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/bin/rustc /build/cargo/target/release/cargo build
Compiling getopts v0.2.14
Compiling log v0.3.6
Compiling libc v0.2.16
Compiling rand v0.3.14
Compiling pulldown-cmark v0.0.3
Compiling tempdir v0.3.5
Compiling skeptic v0.5.0
Compiling read-process-memory v0.1.2-pre (file:///build/read-process-memory)
Finished dev [unoptimized + debuginfo] target(s) in 7.31 secs
real 0m7.733s
user 0m0.060s
sys 0m0.036s
luser@eye7:/build/read-process-memory$ /build/cargo/target/release/cargo clean; time RUSTC_WRAPPER=/build/sccache2/target/release/sccache RUSTC=/home/luser/.rustup/toolchains/beta-x86_64-unknown-linux-gnu/bin/rustc /build/cargo/target/release/cargo build
Compiling getopts v0.2.14
Compiling libc v0.2.16
Compiling log v0.3.6
Compiling pulldown-cmark v0.0.3
Compiling rand v0.3.14
Compiling tempdir v0.3.5
Compiling skeptic v0.5.0
Compiling read-process-memory v0.1.2-pre (file:///build/read-process-memory)
Finished dev [unoptimized + debuginfo] target(s) in 0.97 secs
real 0m1.049s
user 0m0.060s
sys 0m0.036s
```
The use of beta rustc is just to pick up the fix for making `--emit=dep-info` faster (which should ship in 1.17). If this patch ships in cargo then in the future developers should simply be able to `cargo install sccache; export RUSTC_WRAPPER=sccache` and `cargo build` as normal, but benefit from local sccache caching.
Auto merge of #3924 - koivunej:issue_3922, r=alexcrichton
Adjust submodule updating failure reporting
This PR changes output of cargo when updating a dependency fails because of it's submodules cannot be loaded. In my original example this was caused by submodule pointing to a revision which was deleted by force pushing. Fixes #3922.
Before:
```
$ cargo check
Updating git repository `<foo-url>`
error: failed to load source for a dependency on `foo`
Caused by:
Unable to update <foo-url>?rev=hash
To learn more, run the command again with --verbose.
```
After:
```
$ cargo check
Updating git repository `<foo-url>`
error: failed to load source for a dependency on `foo`
Caused by:
Unable to update <foo-url>?rev=hash
Caused by:
Failed to update submodule `submodule`
To learn more, run the command again with --verbose.
```
`--verbose` showing an additional `[9/-3] object not found - no match for id (hash)` has not been changed.
@alexcrichton since we have this nice timezone difference there was no chance of mentoring so far but any comments/suggestions are highly welcome. I'll likely check back on this next week.
Now instead of reporting single generic "submodule update failed" a
dependency specific submodule update failed error message will be
reported and shown without --verbose.
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.
projects / cargo.git / log