bors [Fri, 29 Jan 2016 22:15:35 +0000 (22:15 +0000)]
Auto merge of #2330 - rillian:fixes, r=alexcrichton
std::slice::SliceConcatExt::connect() was deprecated in 1.3.0
and renamed to join(). Now that 1.6.0 is the stable release,
we can transition to the newer method name.
Ralph Giles [Fri, 29 Jan 2016 21:27:20 +0000 (13:27 -0800)]
Replace deprecated slice::connect with slice::join.
std::slice::SliceConcatExt::connect() was deprecated in 1.3.0
and renamed to join(). Now that 1.6.0 is the stable release,
we can transition to the newer method name.
bors [Fri, 29 Jan 2016 04:10:44 +0000 (04:10 +0000)]
Auto merge of #2327 - alexcrichton:ustar-archives, r=alexcrichton
The tar::Builder type by default will build GNU archives, but
unfortunately we force it here to use UStar archives instead. The
UStar format has more limitations on the length of path name that it
can encode, so it's not quite as nice to use.
Older cargos, however, had a bug where GNU archives were interpreted
as UStar archives. This bug means that if we publish a GNU archive
which has fully filled out metadata it'll be corrupt when unpacked by
older cargos.
Hopefully in the future after enough cargos have been running around
with the bugfixed tar-rs library we'll be able to switch this over to
GNU archives, but for now we'll just say that you can't encode paths
in archives that are *too* long.
Alex Crichton [Fri, 29 Jan 2016 04:07:56 +0000 (20:07 -0800)]
Build UStar archives by default
The tar::Builder type by default will build GNU archives, but
unfortunately we force it here to use UStar archives instead. The
UStar format has more limitations on the length of path name that it
can encode, so it's not quite as nice to use.
Older cargos, however, had a bug where GNU archives were interpreted
as UStar archives. This bug means that if we publish a GNU archive
which has fully filled out metadata it'll be corrupt when unpacked by
older cargos.
Hopefully in the future after enough cargos have been running around
with the bugfixed tar-rs library we'll be able to switch this over to
GNU archives, but for now we'll just say that you can't encode paths
in archives that are *too* long.
bors [Mon, 25 Jan 2016 21:50:36 +0000 (21:50 +0000)]
Auto merge of #2319 - alexcrichton:compat-12, r=brson
There hasn't actually ever been a request to maintain compatibility with older
stable Rust versions, and it's becoming a bit of a maintenance burden, so just
switch CI to run on stable Rust.
Alex Crichton [Mon, 25 Jan 2016 20:52:23 +0000 (12:52 -0800)]
Remove 1.2.0 from .travis.yml
There hasn't actually ever been a request to maintain compatibility with older
stable Rust versions, and it's becoming a bit of a maintenance burden, so just
switch CI to run on stable Rust.
bors [Mon, 25 Jan 2016 17:56:00 +0000 (17:56 +0000)]
Auto merge of #2196 - matklad:metadata2, r=alexcrichton
Most of the work was done by @dan-t in #1225 and by @winger in #1434
Fixes #2193
I failed to properly rebase previous attempts so I just salvaged this from bits and pieces.
@alexcrichton are you sure that the default format should be TOML? I think that TOML is more suitable for humans, and JSON is better (at the moment at least) for tools. Maybe we should default to ~~TOML~~ JSON?
bors [Sun, 24 Jan 2016 18:42:32 +0000 (18:42 +0000)]
Auto merge of #2081 - vi:cargo_init, r=alexcrichton
Implement `cargo init` command and appropriate tests ( #21).
Features:
* Working like `cargo new` if there are no files in current directory
* Auto-detection of `--bin`
* Auto-detection of already existing VSC and appending to respecive ignore file
* Appending of appropriate `[lib]` or `[[bin]]` section to `Cargo.toml` in case of some non-standard source locations
Concerns:
* I'm not experienced in Rust + lazy => code looks poorer compared to the rest Cargo code
* The test don't cover 100% of functions
* Project consisting of both binary and library is not handled
* Many deviations from [previously proposed algorithm](https://github.com/rust-lang/cargo/pull/2008#issuecomment-145607870)
When non-existing directory is provided as argument, it
works just like "cargo new".
When existing directory is used, it may also create template
source file like "cargo new" or may find and use existing
source code for Cargo.toml.
Squashed commit of the following:
cargo init: Supply USER envvar for one test
cargo init: Other message when Cargo.toml already exists
cargo init: Resolve conflict after with #2257
fix minor issues
cargo new/init: Simplify error handling code in entry points
cargo new/init: Better message for invalid characters in name
cargo init: fix minor issues in test
cargo init: Avoid excessive builds in the test
cargo init: minor fixes
cargo init: Skip no_filename test on Windows
cargo init: Implement better error message for bin name clash
cargo init: minor fixes
cargo init: handle "/" path
cargo init: Actualise
cargo new: Fix upper case error message in test
cargo init: Remove paths::{file,directory}_already_exists
fix uppper-case error messages
cargo init: Fix minor issues per diff comments
cargo init: Change binary handling
cargo init: Move multiple lib error detection away from mk
cargo init: Support optional path argument
cargo init: Fix minor issues per Github comments
cargo init: Fix complaint from tests/check-style.sh
cargo init: Handle projects with multiple mains
cargo init: Major refactor, multi-target projects
cargo init: Add Cargo.lock unconditionally
cargo init: Fix complains from tests/check-style.sh
cargo init: Tests for handling VCS
cargo init: Handle VCS
cargo init: work in progress
cargo init: Deduplicate some things between new and init
cargo init: Auto-detection of --bin
cargo init: work in progress...
cargo init: Fix tests and allow explicit --vcs
cargo init: intermediate refactor
cargo init: First sketch of implementation
cargo init: Preliminary test
cargo init: first stub
See
https://github.com/vi/cargo/tree/cargo_init_unsquashed
for individual commits
bors [Sat, 23 Jan 2016 00:21:03 +0000 (00:21 +0000)]
Auto merge of #2307 - alexcrichton:readme, r=brson
Running `cargo build` should work just fine to build cargo as well as not
running the python script to download rustc itself. Now that Cargo runs on
stable (and a pretty old stable) most Rust installations should "Just Work" to
build Cargo.
Alex Crichton [Sat, 23 Jan 2016 00:09:17 +0000 (16:09 -0800)]
Add more info to README about compiling
Running `cargo build` should work just fine to build cargo as well as not
running the python script to download rustc itself. Now that Cargo runs on
stable (and a pretty old stable) most Rust installations should "Just Work" to
build Cargo.
bors [Wed, 20 Jan 2016 19:41:06 +0000 (19:41 +0000)]
Auto merge of #2296 - alexcrichton:wow-thats-a-bad-bug, r=brson
There was a previous bug where if any crate's name was the start of the crate
being updated that the crate wouldn't resolve at all, and this fixes the prefix
checking error bug.
bors [Wed, 20 Jan 2016 17:36:59 +0000 (17:36 +0000)]
Auto merge of #2270 - felixc:warn-on-empty-dep, r=alexcrichton
This warns when encountering dependencies of either of these forms:
```
[dependencies]
foo = {}
```
and
```
[dependencies.foo]
```
(with nothing further provided).
In the future, this should likely become a hard error.
bors [Tue, 19 Jan 2016 23:05:06 +0000 (23:05 +0000)]
Auto merge of #2282 - mcarton:clippy, r=alexcrichton
For information, here is the [log before and after](https://gist.github.com/mcarton/684c030321c4c60d6bc9) with Clippy.
Remaining warnings from Clippy are mostly false positive or `str` to `string` conversion (too many of them for this PR).
Alex Crichton [Tue, 19 Jan 2016 20:06:58 +0000 (12:06 -0800)]
Fix update --precise with the registry source
There was a previous bug where if any crate's name was the start of the crate
being updated that the crate wouldn't resolve at all, and this fixes the prefix
checking error bug.
bors [Fri, 15 Jan 2016 21:36:03 +0000 (21:36 +0000)]
Auto merge of #2281 - rillian:doc-nocapture, r=alexcrichton
Although this is a feature of rustc's test harness and
not cargo's test driver, I can never remember how to
invoke it. Describing the switch in `cargo test --help`
makes it more discoverable.
Ralph Giles [Fri, 15 Jan 2016 16:59:55 +0000 (08:59 -0800)]
Document --nocapture to reduce confusion running tests.
Although this is a feature of rustc's test harness and
not cargo's test driver, I can never remember how to
invoke it. Describing the switch in `cargo test --help`
makes it more discoverable.
bors [Fri, 15 Jan 2016 00:40:34 +0000 (00:40 +0000)]
Auto merge of #2279 - alexcrichton:rerun-if-changed-rust-file, r=brson
There was a failure mode of the handling of the rerun-if-changed directive where
it would rerun the build script twice before hitting a steady state of actually
processing the directives. The order of events that led to this were:
1. A project was built from a clean directory. Cargo recorded a fingerprint
indicating this (for the build script), but the fingerprint indicated that
the build script was a normal build script (no manually specified inputs)
because Cargo had no prior knowledge.
2. A project was then rebuilt from the same directory. Cargo's new fingerprint
for the build script now indicates that there is a custom list of
dependencies, but the previous fingerprint indicates there wasn't, so the
mismatch causes another rebuild.
3. All future rebuilds will agree that there are custom lists both before and
after, so the directives are processed as one would expect.
This commit does a bit of refactoring in the fingerprint module to fix this
situation. The recorded fingerprint in step (1) is now recorded as a "custom
dependencies are specified" fingerprint if, after the build script is run,
custom dependencies were specified.
Alex Crichton [Wed, 13 Jan 2016 01:37:57 +0000 (17:37 -0800)]
Handle rerun-if-changed directives in dependencies
There was a failure mode of the handling of the rerun-if-changed directive where
it would rerun the build script twice before hitting a steady state of actually
processing the directives. The order of events that led to this were:
1. A project was built from a clean directory. Cargo recorded a fingerprint
indicating this (for the build script), but the fingerprint indicated that
the build script was a normal build script (no manually specified inputs)
because Cargo had no prior knowledge.
2. A project was then rebuilt from the same directory. Cargo's new fingerprint
for the build script now indicates that there is a custom list of
dependencies, but the previous fingerprint indicates there wasn't, so the
mismatch causes another rebuild.
3. All future rebuilds will agree that there are custom lists both before and
after, so the directives are processed as one would expect.
This commit does a bit of refactoring in the fingerprint module to fix this
situation. The recorded fingerprint in step (1) is now recorded as a "custom
dependencies are specified" fingerprint if, after the build script is run,
custom dependencies were specified.
bors [Tue, 12 Jan 2016 17:18:05 +0000 (17:18 +0000)]
Auto merge of #2269 - felixc:package-untracked-files, r=alexcrichton
The logic in `sources/path.rs` that finds files that are untracked by the version control system was incorrectly including files that *are* tracked, but had been modified without the modification being committed to Git.
This manifested itself as strange duplications of files (e.g. in `cargo package --list`), since they were listed once as tracked files, and once more as allegedly "untracked" ones. It also caused failures when trying to package the crate when files had been deleted, but the deletion was not yet committed to Git.
Felix Crux [Sun, 10 Jan 2016 19:47:02 +0000 (14:47 -0500)]
Fix listing of untracked files to not include tracked but modified ones
The logic in `sources/path.rs` that finds files that are untracked by the
version control system was incorrectly including files that *are* tracked,
but had been modified without the modification being committed to Git.
This manifested itself as strange duplications of files (e.g. in `cargo
package --list`), since they were listed once as tracked files, and once
more as allegedly "untracked" ones. It also caused failures when trying to
package the crate when files had been deleted, but the deletion was not
yet committed to Git.
Tobias Bucher [Fri, 18 Dec 2015 12:27:08 +0000 (12:27 +0000)]
Only treat missing crate lists as empty
The motivation is that errors other than "file not found" could lead to
the file being overwritten by an empty config, e.g. if the `open` call
is interrupted and returns `EINTR`, then this code would read an empty
config and write it back later on. This can probably happen for other
errors as well (`ENFILE`, ...).
Without actually giving anything to link (for example, because the code
contains `#[link(name="foo")]`. In this case, we aren't actually passing
`-L` through when running doctests, even though they're passed when
compiling the main crate.
Sean Griffin [Sat, 19 Dec 2015 19:44:34 +0000 (12:44 -0700)]
Remove needless dylib check, add test
In this case the dylib check isn't actually doing anything useful, as
we're just appending search paths. Also adds a test for 8c65284b44337c6cfc003cedc8996e241ac678bd
bors [Fri, 18 Dec 2015 18:43:14 +0000 (18:43 +0000)]
Auto merge of #2223 - alexcrichton:better-dev-experience, r=brson
Each test wants to be sure to reset HOME and remove CARGO_HOME from the
environment, but this was done inconsistently throughout the test suite. This
commit consolidates process creation so there's only one point for creating a
process ready to execute the Cargo that's being tested.
bors [Thu, 17 Dec 2015 23:08:10 +0000 (23:08 +0000)]
Auto merge of #2219 - matklad:encodable-audit, r=alexcrichton
@alexcrichton another preparation PR for #2196
I've removed obscure `metadata` field from `Target`. It is a breaking change (for read-manifest), but the field seemed cryptic, useless and untested :)
`Target` has a bunch of boolean fields:
```
tested: bool,
benched: bool,
doc: bool,
doctest: bool,
harness: bool, // whether to use the test harness (--test)
for_host: bool,
```
I guess they should not be included in serialized representation?