bors [Thu, 26 Jan 2017 22:27:33 +0000 (22:27 +0000)]
Auto merge of #3597 - Susurrus:badge_docs, r=alexcrichton
Add gitlab to the supported services for AppVeyor badges.
This is undocumented but supported behavior for AppVeyor. I have already done this with a crate I own and the badge works on both the AppVeyor and crates.io end.
bors [Fri, 20 Jan 2017 18:48:12 +0000 (18:48 +0000)]
Auto merge of #3554 - bmwiedemann:patch-1, r=alexcrichton
make build reproducible
see https://reproducible-builds.org/ for why this is good
and https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal#Bash_.2F_POSIX_shell for variants that also work on BSD
bors [Thu, 19 Jan 2017 23:43:24 +0000 (23:43 +0000)]
Auto merge of #3565 - integer32llc:fix-gh-pages, r=alexcrichton
Fix doc publishing: Remove $USER from the --user argument from pip install
[This looks to be the cause of why docs aren't publishing to gh-pages](https://travis-ci.org/rust-lang/cargo/jobs/193507734#L1059). I was able to publish the docs to [my repo's gh-pages](https://integer32llc.github.io/cargo/) with this change (and setting my own secure gh-token).
It looks like this problem got introduced [in this commit](https://github.com/rust-lang/cargo/commit/dc15ca5d202d6d10f6be45f388759a902723de6c). I don't really know python/pip, but `$USER` wasn't there before and [Travis' docs just say `--user`](https://docs.travis-ci.com/user/languages/python/#pip).
Since `--test` works for rustc, doctests should also work. Currently cargo isn't setup to run doctests for proc macro crates, this PR adds them to the list.
Currently rustdoc can run doctests for proc-macro crates, but the `phase_2_configure_and_expand` call` triggers the following warning:
```
the `#[proc_macro_derive]` attribute is only usable with crates of the `proc-macro` crate type
```
So perhaps this PR should wait until I've finished creating/testing the PR for rustc.
bors [Tue, 17 Jan 2017 22:40:07 +0000 (22:40 +0000)]
Auto merge of #3546 - integer32llc:badgers, r=alexcrichton
Upload Travis CI and Appveyor badge metadata specified in the manifest
This goes with rust-lang/crates.io#504. This has cargo upload badge metadata to crates.io on publish, and will print any warnings it gets back from crates.io about unknown badges or missing required badge attributes!
This will definitely cause some merge conflicts with #3301, I'll watch and fix whichever one gets merged 2nd :)
bors [Tue, 17 Jan 2017 18:57:20 +0000 (18:57 +0000)]
Auto merge of #3301 - integer32llc:categories, r=alexcrichton
Upload categories specified in the manifest
This adds support for uploading categories to crates.io, if they are specified in the manifest.
This goes with rust-lang/crates.io#473. It should be fine to merge this PR either before or after that one; crates.io master doesn't care if the categories are in the metadata or not. With that PR, I was able to use this patch with cargo to add categories to a crate!
bors [Tue, 17 Jan 2017 02:48:37 +0000 (02:48 +0000)]
Auto merge of #3542 - creativcoder:check-digit-name, r=alexcrichton
Add a check for names starting with a digit
According to Rust grammer https://doc.rust-lang.org/grammar.html#extern-crate-declarations for extern crate declarations, a crate name cannot start with a digit.
But, currently this rule is not upheld by `cargo new` as creating a project like:
`cargo new 2048` would create a project named 2048 which obviously won't compile with crate declaration like `extern crate 2048` by a consumer.
This obviously is a rare case in practice, but its always good to check i guess.
This PR adds a check to the `new` method and `bail`s out with a message for any names starting with a digit.
PS: I noticed it while making a 2048 puzzle game as a library so thought it would be nice to add this check :)
bors [Thu, 12 Jan 2017 07:56:39 +0000 (07:56 +0000)]
Auto merge of #3533 - jtgeibel:3519-dev-target, r=alexcrichton
Rename debug target to dev in build output
This renames the debug target to dev in the build output for non-release
builds. This includes the output of commands such as `cargo build`,
`cargo test`, and `cargo doc`.
bors [Thu, 12 Jan 2017 05:56:12 +0000 (05:56 +0000)]
Auto merge of #3532 - alexcrichton:ignore, r=brson
Ignore spuriously failing Windows test
I really have no clue why this test is failing on Windows, and after months of
being unable to diagnose I'm tired of retrying PRs due to this failure. Let's
just ignore it on Windows.
bors [Thu, 12 Jan 2017 04:03:27 +0000 (04:03 +0000)]
Auto merge of #3490 - alexcrichton:dev-dep-doc-test, r=brson
Fix cargo test --doc with dev-deps
Previously Cargo accidentally didn't pull in dev-dependencies due to the way
`cargo test --doc` was interpreted in terms of top-level targets. This PR
special cases this situation by ensuring that the doctest intention makes its
way all to the backend and the dependencies can be correctly calculated.
Justin Geibel [Thu, 12 Jan 2017 01:03:36 +0000 (20:03 -0500)]
Rename debug target to dev in build output
This renames the debug target to dev in the build output for non-release
builds. This includes the output of commands such as `cargo build`,
`cargo test`, and `cargo doc`.
bors [Thu, 12 Jan 2017 02:03:34 +0000 (02:03 +0000)]
Auto merge of #3478 - alexcrichton:lift, r=brson
Lift up workspace rlibs while building
I think the condition here was slightly off from before, so invert it subtly to
get what we want, lifting up anything in a workspace or binaries otherwise.
Alex Crichton [Thu, 12 Jan 2017 00:45:29 +0000 (16:45 -0800)]
Ignore spuriously failing Windows test
I really have no clue why this test is failing on Windows, and after months of
being unable to diagnose I'm tired of retrying PRs due to this failure. Let's
just ignore it on Windows.
bors [Thu, 12 Jan 2017 00:45:23 +0000 (00:45 +0000)]
Auto merge of #3527 - nikomatsakis:master, r=alexcrichton
check for `CARGO_INCREMENTAL` and pass `-Zincremental` if present
Per the discussion on IRC, this adds a very simple way for cargo users to opt into incremental compilation by setting the `CARGO_INCREMENTAL` environment variable (i.e., `CARGO_INCREMENTAL=1 cargo build`). This will result in incremental data being stored into the `target/incremental` directory. Since it supplies `-Z`, this option is only intended for use on nightly compilers, though cargo makes no effort to check.
The plan is to keep incremental compilation optional until we are feeling more confident it's not going to cause problems for people. At that point, it should become part of the compilation profile. It will be the default when building in debug builds, and opt-in for release builds.
bors [Mon, 9 Jan 2017 04:20:40 +0000 (04:20 +0000)]
Auto merge of #3510 - froydnj:cross-compilation-test-checking, r=alexcrichton
handle cross-compilation test failure more gracefully
The current cross-compilation test module fails every test if an appropriate cross standard library is not found. This behavior is unhelpful, because the failures are verbose, unexpected, and there's no
obvious way to make them go away.
Instead, it would be better to check once before all the tests that an appropriate cross-compilation setup is available. Once that check has been done, a single test can fail with an appropriate `panic!` message while the other tests silently pass. The `panic!` message can inform the user about their options, either setting an appropriate environment variable, or using rustup to install the necessary cross standard library.
Assuming the user has rustup installed, the single failure now looks
something like:
```
thread 'plugin_deps' panicked at 'Cannot cross compile to i686-unknown-linux-gnu.
This failure can be safely ignored. If you would prefer to not see this
failure, you can set the environment variable CFG_DISABLE_CROSS_TESTS to "1".
Alternatively, you can install the necessary libraries for cross-compilation with
rustup toolchain install stable-i686-unknown-linux-gnu
', tests/cross-compile.rs:87
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
The code is admittedly gnarly, with synchronization and `unsafe` sections, but I wasn't sure how to make it any better. Suggestions welcome!
Nathan Froyd [Fri, 6 Jan 2017 19:30:38 +0000 (14:30 -0500)]
handle cross-compilation test failure more gracefully
The current cross-compilation test module fails every test if an
appropriate cross standard library is not found. This behavior is
unhelpful, because the failures are verbose, unexpected, and there's no
obvious way to make them go away.
Instead, it would be better to check once before all the tests that an
appropriate cross-compilation setup is available. Once that check has
been done, a single test can fail with an appropriate `panic!` message
while the other tests silently pass. The `panic!` message can inform
the user about their options, either setting an appropriate environment
variable, or using rustup to install the necessary cross standard
library.
Assuming the user has rustup installed, the single failure now looks
something like:
```
thread 'plugin_deps' panicked at 'Cannot cross compile to i686-unknown-linux-gnu.
This failure can be safely ignored. If you would prefer to not see this
failure, you can set the environment variable CFG_DISABLE_CROSS_TESTS to "1".
Alternatively, you can install the necessary libraries for cross-compilation with
You may need to install runtime libraries for your Linux distribution as well.
', tests/cross-compile.rs:87
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
bors [Fri, 6 Jan 2017 20:57:04 +0000 (20:57 +0000)]
Auto merge of #3509 - froydnj:colored-shell-tests, r=alexcrichton
disable color shell tests for terminals that don't support color
Some terminals (e.g. running a shell inside Emacs's shell-mode) don't
support color, and running tests that assume the terminal supports color
don't work so well. Instead, if color is expected, check the terminal
for whether it supports color or not, and act accordingly.
Nathan Froyd [Fri, 6 Jan 2017 17:46:56 +0000 (12:46 -0500)]
disable color shell tests for terminals that don't support color
Some terminals (e.g. running a shell inside Emacs's shell-mode) don't
support color, and running tests that assume the terminal supports color
don't work so well. Instead, if color is expected, check the terminal
for whether it supports color or not, and act accordingly.
bors [Fri, 6 Jan 2017 06:15:35 +0000 (06:15 +0000)]
Auto merge of #3427 - nrc:api-check-2, r=alexcrichton
Make some aspects of check/build available as an API.
There are two key parts to this commit:
* let API clients run `cargo check` with minimal fuss (ops/cargo_check.rs),
* let API clients intercept and customise Cargo's calls to rustc (all the Executor stuff).
Alex Crichton [Tue, 20 Dec 2016 00:28:06 +0000 (16:28 -0800)]
Fix cargo test --doc with dev-deps
Previously Cargo accidentally didn't pull in dev-dependencies due to the way
`cargo test --doc` was interpreted in terms of top-level targets. This PR
special cases this situation by ensuring that the doctest intention makes its
way all to the backend and the dependencies can be correctly calculated.
Alex Crichton [Fri, 30 Dec 2016 18:50:39 +0000 (10:50 -0800)]
Lift up workspace rlibs while building
I think the condition here was slightly off from before, so invert it subtly to
get what we want, lifting up anything in a workspace or binaries otherwise.
projects / cargo.git / log