bors [Tue, 18 Oct 2016 16:07:50 +0000 (09:07 -0700)]
Auto merge of #3149 - cardoe:fix-pkgid-cmd, r=alexcrichton
pkgid cmd: fix help msg with multiple packages
When there are multiple versions of a package that match a given spec
the command tells you to re-run it with the `-p` argument which does not
exist. The command appears to work without it properly.
Doug Goldstein [Tue, 18 Oct 2016 05:24:53 +0000 (00:24 -0500)]
pkgid: add the -p flag as the output suggests
When you use this command and there are multiple packages that match
this spec, the help instructions tell you to rerun it with the -p
argument which was previously not present. Since the code paths are
shared with 'cargo build' and 'cargo update', this adds the -p argument
to 'cargo pkgid' to make things more consistent.
bors [Mon, 17 Oct 2016 15:47:36 +0000 (08:47 -0700)]
Auto merge of #3205 - matklad:fix-rustdoc-ld-path, r=alexcrichton
Pass target environment for rustdoc
This should fix #3200, but I am not sure that this is a correct fix, and I need some input to figure this out.
`rustdoc` is invoked in two places, in `cargo_test.rs` and in `cargo_rustc/mod.rs`. Before the refactoring PR, these invocations used different LD_LIBRARY paths. [The one in cargo_rustc](https://github.com/rust-lang/cargo/pull/3198/files#diff-59acd1a3101aebbb591ac7ab51c19d9eR427) used "host" version, while [the one in cargo_test](https://github.com/rust-lang/cargo/blob/a8baa5b8f36e88170c8c56523b6eb72efc2cc55e/src/cargo/ops/cargo_test.rs#L131) used "target" version.
The original PR changed both to "host", this PR switches both to "target". Is this correct, or should we stick with different environments for building documentation and doctests?
bors [Thu, 13 Oct 2016 18:22:15 +0000 (11:22 -0700)]
Auto merge of #3198 - matklad:kill-command-type, r=alexcrichton
Remove CommandType struct
This removes `CommandType` struct as well as `cargo_rustc::process` function. So now all process creation goes thorough methods of `Compilation`.
This does change search path order from `util::dylib_path(), host_dylib_path()` to `host_dylib_path(), util::dylib_path()`, but I hope this is not a problem.
This also uncovers the fact that `rustdoc` is run sometimes with and sometimes without `host_dylib_path`. Is this intentional?
bors [Wed, 12 Oct 2016 14:24:47 +0000 (07:24 -0700)]
Auto merge of #3193 - matklad:kill-command-proto, r=alexcrichton
Remove command prototype
A followup of #3177 . I am not sure, but perhaps we can remove/refactor `CommandType` as well: for each command variant, `Compilation` as a public dedicated method, but it also has a generic one (`process`) (haha: https://github.com/rust-lang/cargo/pull/1107/files#r22429844).
bors [Tue, 11 Oct 2016 20:40:36 +0000 (13:40 -0700)]
Auto merge of #3187 - edunham:appveyor-gnu, r=alexcrichton
Add GNU triples for #3186
Resources used to take an educated guess at this:
* Servo's appveyor.yml
* Rust's Buildbot config
* Alex
* Some random appveyor config that Alex had sitting around
bors [Sun, 9 Oct 2016 17:12:36 +0000 (10:12 -0700)]
Auto merge of #3183 - rjgoldsborough:broken-docs-links, r=alexcrichton
removing return false causing links to break
Gah! Sorry about that.
fixes #3182
I added a `return false` to the function above to prevent it from toggling itself back off but for some reason put one here as well which stopped the event before the link could fire.
bors [Fri, 7 Oct 2016 20:09:27 +0000 (13:09 -0700)]
Auto merge of #3154 - steveklabnik:gh3124, r=alexcrichton
upgrade semver
This is a spike at fixing #3124.
@alexcrichton I'm not sure how to actually emit the error message here. In the TOML example you linked me: https://github.com/rust-lang/cargo/blob/5593045ddef2744c1042dee0c0037c2ebcc1834e/src/cargo/util/toml.rs#L166
That takes a Config as an argument. This function does not. What's the right approach here?
Also, this code is messy. I am 99% sure I can write it nicer with combinators. This is just to get the discussion going.
bors [Fri, 7 Oct 2016 18:41:31 +0000 (11:41 -0700)]
Auto merge of #3177 - matklad:kill-exec-engine, r=alexcrichton
Remove ExecEngine abstraction
Hi! Not sure what was the idea behind exec engine (perhaps to allow swapping it out during tests?), but looks like it does absolutely nothing at the moment, and can be removed.
bors [Thu, 6 Oct 2016 21:03:22 +0000 (14:03 -0700)]
Auto merge of #3000 - matklad:error-format, r=alexcrichton
Add --message-format flag.
Closes #2982
This adds a `--message-format` flag with values `human` or `json-v1` to commands that may trigger compilation.
After the discussion in the issue I am no longer sure that this is a way to go:
* Looks like it buys nothing compared to `RUST_FLAGS` approach: a flag is more useful on the command line, but from the tool point of view there should be no significant differences between a flag and an environmental variable.
* Looks like we really want to wrap compiler's messages into our own json to tie them to particular compilation.
bors [Thu, 6 Oct 2016 03:48:12 +0000 (20:48 -0700)]
Auto merge of #3137 - alexcrichton:bump-curl, r=brson
Update curl to track more error info
This hopefully will help out with https://github.com/rust-lang/cargo/issues/2464#issuecomment-250583778 by including https://github.com/alexcrichton/curl-rust/commit/07323ab5e868babb7a5437e8d2604761b913dab3 which should give us more information from libcurl
bors [Thu, 6 Oct 2016 02:26:10 +0000 (19:26 -0700)]
Auto merge of #3145 - alexcrichton:rustdoc-cross-test, r=brson
Test requested --target from source of truth
We skip doc tests for any cross compiles (as they don't work) but to detect a
cross compile we checked `--target` but forgot to check other locations like
`CARGO_BUILD_TARGET` or `[build.target]`. This alters the check to ensure that
it verifies from the source of truth whether a cross compilation happened or
not.
bors [Thu, 6 Oct 2016 00:40:11 +0000 (17:40 -0700)]
Auto merge of #3136 - alexcrichton:warn-bad-override, r=brson
Warn about path overrides that won't work
Cargo has a long-standing [bug] in path overrides where they will cause spurious
rebuilds of crates in the crate graph. This can be very difficult to diagnose
and be incredibly frustrating as well. Unfortunately, though, it's behavior that
fundamentally can't be fixed in Cargo.
The crux of the problem happens when a `path` replacement changes something
about the list of dependencies of the crate that it's replacing. This alteration
to the list of dependencies *cannot be tracked by Cargo* as the lock file was
previously emitted. In the best case this ends up causing random recompiles. In
the worst case it cause infinite registry updates that always result in
recompiles.
A solution to this intention, changing the dependency graph of an overridden
dependency, was [implemented] with the `[replace]` feature in Cargo awhile back.
With that in mind, this commit implements a *warning* whenever a bad dependency
replacement is detected. The message here is pretty wordy, but it's intended to
convey that you should switch to using `[replace]` for a more robust
impelmentation, and it can also give security to anyone using `path` overrides
that if they get past this warning everything should work as intended.
bors [Wed, 5 Oct 2016 23:22:25 +0000 (16:22 -0700)]
Auto merge of #3144 - alexcrichton:less-update-registry, r=brson
Avoid updating registry when adding existing deps
Cargo previously erroneously updated the registry whenever a new dependency was
added on a crate which already exists in the DAG. This commit fixes this
behavior by ensuring that if the new dependency matches a previously locked
version it uses that instead.
This commit involved a bit of refactoring around this logic to be a bit more
clear how the locking and "falling back to the registry" is happening.
bors [Mon, 3 Oct 2016 08:43:02 +0000 (01:43 -0700)]
Auto merge of #3150 - matklad:deprecate-read-manifest, r=alexcrichton
Document that read_manifest command is deprecated
I believe we intended to deprecate read_manifest command. I am not sure what a deprecation process for Cargo commands should be, but I guess it should involve mentioning somewhere that the command is deprecated :)
bors [Mon, 3 Oct 2016 07:06:51 +0000 (00:06 -0700)]
Auto merge of #3147 - carols10cents:versions-in-readme, r=alexcrichton
Add information about Cargo releases going with Rust releases
Closes #3101.
This just adds a table of rust release numbers to cargo release numbers, and some text that clarifies that they happen together.
I put the table behind a details tag, which Chrome renders really nicely with a little toggle triangle... Firefox will do the toggling *functionality* but doesn't have much of an indication that you can click on the text, but I think they're working on it. Servo has a little triangle but nothing happens when you click on it ;)
Alex Crichton [Fri, 30 Sep 2016 20:07:37 +0000 (13:07 -0700)]
Test requested --target from source of truth
We skip doc tests for any cross compiles (as they don't work) but to detect a
cross compile we checked `--target` but forgot to check other locations like
`CARGO_BUILD_TARGET` or `[build.target]`. This alters the check to ensure that
it verifies from the source of truth whether a cross compilation happened or
not.
Alex Crichton [Thu, 21 Jul 2016 16:50:33 +0000 (09:50 -0700)]
Avoid updating registry when adding existing deps
Cargo previously erroneously updated the registry whenever a new dependency was
added on a crate which already exists in the DAG. This commit fixes this
behavior by ensuring that if the new dependency matches a previously locked
version it uses that instead.
This commit involved a bit of refactoring around this logic to be a bit more
clear how the locking and "falling back to the registry" is happening.
Alex Crichton [Thu, 29 Sep 2016 23:35:22 +0000 (16:35 -0700)]
Warn about path overrides that won't work
Cargo has a long-standing [bug] in path overrides where they will cause spurious
rebuilds of crates in the crate graph. This can be very difficult to diagnose
and be incredibly frustrating as well. Unfortunately, though, it's behavior that
fundamentally can't be fixed in Cargo.
The crux of the problem happens when a `path` replacement changes something
about the list of dependencies of the crate that it's replacing. This alteration
to the list of dependencies *cannot be tracked by Cargo* as the lock file was
previously emitted. In the best case this ends up causing random recompiles. In
the worst case it cause infinite registry updates that always result in
recompiles.
A solution to this intention, changing the dependency graph of an overridden
dependency, was [implemented] with the `[replace]` feature in Cargo awhile back.
With that in mind, this commit implements a *warning* whenever a bad dependency
replacement is detected. The message here is pretty wordy, but it's intended to
convey that you should switch to using `[replace]` for a more robust
impelmentation, and it can also give security to anyone using `path` overrides
that if they get past this warning everything should work as intended.
This would still download foo version 0.2.0 on unix. I think there is no need to do that, but please correct me if I'm wrong.
This was triggered by [this](http://stackoverflow.com/questions/39709542/why-does-the-last-platform-specific-dependency-take-precedence-in-cargo) stackoverflow question, but that situation is more complicated, as the version is the same, just the features are different. This PR will not solve that bug. If you want me to include that too, I would have to debug a bit more first....
Auto merge of #3089 - carols10cents:crates-io-registry-url, r=alexcrichton
Make crates-io registry URL optional in config; ignore all changes to source.crates-io
Hi! When I was working on the instructions for source replacement [in this crates.io PR](https://github.com/rust-lang/crates.io/pull/440), I found that when I'm replacing `source.crates-io`, [I still have to specify some value for `registry`](https://github.com/rust-lang/crates.io/pull/440/files#diff-04c6e90faac2675aa89e2176d2eec7d8R177), or else I get this:
```
error: no source URL specified for `source.crates-io`, need either `registry` or `local-registry` defined
```
This seems weird and annoying to me: cargo definitely knows the registry URL for crates-io, and I'm trying to replace it anyway.
So the first commit in this PR makes it optional, so that you don't have to specify a registry url for crates-io: it uses `SourceId::crates_io`, like it would if we didn't have any source configs at all.
~~The second commit in this PR might go too far, and/or might break existing uses of cargo, I'm not sure. In my opinion, `source.crates-io` should only be able to be replaced and never changed directly-- crates-io should always be crates-io, and I should be able to assume that in any project. So the second commit ignores all modifications to `source.crates-io`'s `registry`, `local-registry`, and `directory`, and warns that they're being ignored.~~
~~I tried to search github to see if anyone was using these keys with `source.crates-io`, but since github's search ignores `.` (ARE YOU LISTENING GITHUB? I WOULD LIKE TO SEARCH WITH PUNCTUATION PLEASE), there's a lot of false positives to wade through. I didn't see anything in the first few pages though.~~
Auto merge of #3118 - cbiffle:master, r=alexcrichton
Fall back to fs::copy when hard_link fails.
Some filesystems don't allow hard links. Since Cargo's use of hard
links is an optimization, and not necessary for correctness, it can fall
back to a file copy when hard linking is not available.
This is one possible solution to #3098.
Caveat: this will try to copy if the hard link fails *for any reason*.
It's not clear that there's a more surgical way of handling this; Unix
tends to indicate the condition as "permission denied," not with a
granular "links not supported by filesystem" error.
Some filesystems don't allow hard links. Since Cargo's use of hard
links is an optimization, and not necessary for correctness, it can fall
back to a file copy when hard linking is not available.
This is one possible solution to #3098.
Caveat: this will try to copy if the hard link fails *for any reason*.
It's not clear that there's a more surgical way of handling this; Unix
tends to indicate the condition as "permission denied," not with a
granular "links not supported by filesystem" error.