bors [Sat, 13 May 2017 18:06:26 +0000 (18:06 +0000)]
Auto merge of #3954 - RReverser:run-with, r=alexcrichton
Add support for custom target-specific runners
When `target.$triple.runner` is specified, it will be used for any execution commands by cargo including `cargo run`, `cargo test` and `cargo bench`. The original file is passed to the runner executable as a first argument.
This allows to run tests when cross-comping Rust projects.
This is not a complete solution and might be extended in future for better ergonomics to support passing extra arguments to the runner itself or overriding runner from the command line, but it should already unlock major existing use cases.
When `target.$triple.runner` is specified, it will be used for any execution commands by cargo including `cargo run`, `cargo test` and `cargo bench`. The original file is passed to the runner executable as a first argument.
This allows to run tests when cross-comping Rust projects.
This is not a complete solution, and might be extended in future for better ergonomics to support passing extra arguments to the runner itself or overriding runner from command line, but it should already unlock major existing usecases.
bors [Thu, 11 May 2017 22:05:55 +0000 (22:05 +0000)]
Auto merge of #4026 - alexcrichton:bare-registry, r=matklad
Don't check out the crates.io index locally
This commit moves working with the crates.io index to operating on the git
object layers rather than actually literally checking out the index. This is
aimed at two different goals:
* Improving the on-disk file size of the registry
* Improving cloning times for the registry as the index doesn't need to be
checked out
The on disk size of my `registry` folder of a fresh check out of the index went
form 124M to 48M, saving a good chunk of space! The entire operation took about
0.6s less on a Unix machine (out of 4.7s total for current Cargo). On Windows,
however, the clone operation went from 11s to 6.7s, a much larger improvement!
Alex Crichton [Wed, 10 May 2017 22:00:33 +0000 (15:00 -0700)]
Don't check out the crates.io index locally
This commit moves working with the crates.io index to operating on the git
object layers rather than actually literally checking out the index. This is
aimed at two different goals:
* Improving the on-disk file size of the registry
* Improving cloning times for the registry as the index doesn't need to be
checked out
The on disk size of my `registry` folder of a fresh check out of the index went
form 124M to 48M, saving a good chunk of space! The entire operation took about
0.6s less on a Unix machine (out of 4.7s total for current Cargo). On Windows,
however, the clone operation went from 11s to 6.7s, a much larger improvement!
bors [Thu, 11 May 2017 20:24:47 +0000 (20:24 +0000)]
Auto merge of #4032 - alexcrichton:retry-500, r=matklad
Automatically retry HTTP requests returning 5xx
This commit implements auto-retry for downloading crates from crates.io whenever
a 5xx response is returned. This should help assist with automatic retries
whenever Cargo attempts to download directly from S3 but S3 returns a 500 error,
which is defined as "please retry again".
This logic may be a little eager to retry *all* 500 errors, but there's a
maximum cap on all retries regardless, so hopefully it doesn't result in too
many problems.
Alex Crichton [Thu, 11 May 2017 19:41:13 +0000 (12:41 -0700)]
Automatically retry HTTP requests returning 5xx
This commit implements auto-retry for downloading crates from crates.io whenever
a 5xx response is returned. This should help assist with automatic retries
whenever Cargo attempts to download directly from S3 but S3 returns a 500 error,
which is defined as "please retry again".
This logic may be a little eager to retry *all* 500 errors, but there's a
maximum cap on all retries regardless, so hopefully it doesn't result in too
many problems.
bors [Tue, 9 May 2017 17:15:40 +0000 (17:15 +0000)]
Auto merge of #4006 - mcgoo:cargo_test_dylib, r=alexcrichton
fix `cargo test` of dylib projects for end user runs too
Fixes running `cargo test` and `cargo test --target <target>` for dylib projects.
Moves the logic just landed in https://github.com/rust-lang/cargo/pull/3996 into cargo itself, so cargo sets the dylib path for anyone running `cargo test` or `cargo run`. Current master sets the dylib path only for `cargo test` on cargo itself.
This PR pins to rustup 1.2.0 for the purposes of testing. If https://github.com/rust-lang-nursery/rustup.rs/pull/1093 ends up working out, then this PR would only be important for non-rustup users and people doing cross testing, `cargo test --target <target>`.
Arguably https://github.com/mcgoo/cargo/blob/ed273851f8bc76f726eda4a2e2a7bb470c3718bc/src/cargo/ops/cargo_rustc/context.rs#L249-L253 should point to lib/rustlib/\<host triple\>/lib instead of sysroot/lib, because I think if the libs are different, you will never be able to compile a working plugin anyway, and for the host=target case you get the lib/rustlib/\<host triple\>/lib anyhow. Is there ever a case where the lib/rustlib/\<host triple\>/lib and sysroot/lib versions of the libs would be expected to differ?
This is not a huge deal for me one way or the other - it doesn't impact my workflow at all. I nearly dropped it when I saw @alexcrichton had made it all work in 3996, but I think it's worth doing because it removes a surprise. It certainly would have saved me a couple of days of confusion. Either way, thanks for looking it over.
bors [Tue, 9 May 2017 15:35:20 +0000 (15:35 +0000)]
Auto merge of #4010 - jonhoo:better-incremental-nightly-test, r=alexcrichton
Bring test of nightly in line with tests
#4000 passes `-Zincremental` to `rustc` only on nightly, but uses a different mechanism for detecting nightly than [cargotest does](https://github.com/rust-lang/cargo/blob/9bf9bddd9297cfb5098be6146d85be551c6d4eff/tests/cargotest/lib.rs#L37). This PR brings the two in line, which should hopefully fix the build failure observed in https://github.com/rust-lang/rust/pull/41830#issuecomment-300052969.
Jim McGrath [Tue, 2 May 2017 15:34:29 +0000 (10:34 -0500)]
fix dynamic library search path for build scripts
Make dynamic library search path handling for build scripts mirror the
behaviour for cargo run etc. -L paths are taken and stripped of the
native= and similar prefixes and added to the dynamic library search
path if they are inside the target dir.
Resolves https://github.com/rust-lang/cargo/issues/3957
bors [Sun, 7 May 2017 18:03:51 +0000 (18:03 +0000)]
Auto merge of #3999 - kureuil:cratesio-676, r=alexcrichton
Document new behavior of crates.io with the documentation field of the manifest
[crates.io](https://crates.io/) now automatically links a crate with its [docs.rs](https://docs.rs/) page if no documentation link was specified in the manifest.
bors [Sun, 7 May 2017 16:24:48 +0000 (16:24 +0000)]
Auto merge of #4000 - jonhoo:only-incremental-on-nightly, r=alexcrichton
Only pass -Zincremental to nightly rustc.
`-Z` can only be used on nightly builds; other builds complain loudly. Since incremental builds only work on nightly anyway, we should silently ignore `CARGO_INCREMENTAL` on anything but nightly. This allows users to always have `CARGO_INCREMENTAL` set without getting unexpected errors on stable/beta builds.
bors [Tue, 2 May 2017 18:35:07 +0000 (18:35 +0000)]
Auto merge of #3951 - alexcrichton:lift-cdylib, r=alexcrichton
Don't use `-C metadata` cdylibs like we do with dylibs
Dylibs don't get any metadata/extra filename info applied to them as "final
targets" because it can mess with system-specific information (e.g. on OSX) so
this just applies the same logic to cdylibs which need similar treatment on more
platforms (like Windows).
Alex Crichton [Mon, 24 Apr 2017 20:41:27 +0000 (13:41 -0700)]
Don't use `-C metadata` cdylibs like we do with dylibs
Dylibs don't get any metadata/extra filename info applied to them as "final
targets" because it can mess with system-specific information (e.g. on OSX) so
this just applies the same logic to cdylibs which need similar treatment on more
platforms (like Windows).
Auto merge of #3970 - golddranks:master, r=alexcrichton
exec (replace the current process) external subcommands instead of running them as child processes.
This fixes https://github.com/rust-lang/cargo/issues/3959 (tested to be working with my yet-to-be-published subcommand, and tested not to break things with `cargo tree` and `cargo outdated`).
Auto merge of #3921 - alexcrichton:less-asserts, r=matklad
Relax overly strict asserts in dependency queue
Don't actually need to assert that these are unique, it works both ways and we
can have flavorful dependency graphs which otherwise trigger the assertions.
Auto merge of #3899 - alexcrichton:vendor-empty-ok, r=matklad
Support vendor dirs with "empty" directories
Looks like when vendor directories are checked into a VCS there's been instances
where deleting a folder in the VCS doesn't fully delete the folder from the
filesystem. This can lead to [spurious errors][moz] that are difficult to debug.
To help handle this tweak directory sources to ignore empty directories or
directories with only dotfiles by default.
Alex Crichton [Thu, 13 Apr 2017 21:40:08 +0000 (14:40 -0700)]
Relax overly strict asserts in dependency queue
Don't actually need to assert that these are unique, it works both ways and we
can have flavorful dependency graphs which otherwise trigger the assertions.
Auto merge of #3955 - RReverser:update-override-docs, r=alexcrichton
Update documentation on overrides
- `target.linker` does not seem to be supported anymore, only `target.$triple.linker` works, so merged these sections.
- Added note about supported `target.$triple.ar`
- target.linker does not seem to be supported anymore, only target.$triple.linker works, so merged these sections.
- Added note about supported target.$triple.ar
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.