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 ;)
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.
Auto merge of #3083 - jhbabon:fix-warning-in-feature-tests, r=alexcrichton
FIX: Properly close dep_feature_in_cmd_line test.
It was including the test `all_features_flag_enables_all_features` inside its function body and it was causing this warning when executing `cargo test`:
```
Compiling cargo v0.13.0 (file:///home/jhbabon/Code/cargo)
tests/features.rs:965:1: 1006:2 warning: function is never used: `all_features_flag_enables_all_features`, #[warn(dead_code)] on by default
tests/features.rs:965 fn all_features_flag_enables_all_features() {
^
tests/features.rs:964:1: 964:8 warning: unused attribute, #[warn(unused_attributes)] on by default
tests/features.rs:964 #[test]
^~~~~~~
Running target/debug/features-e37991fdf417989c
```
Auto merge of #3078 - jhbabon:fix/parse-home-config-once, r=alexcrichton
Fix: Don't parse the home directory more than once
This PR tries to resolve this issue https://github.com/rust-lang/cargo/issues/3070. The problem is that the `walk_tree` method in the `src/util/config.rs` module was parsing more than once the contents of the config file in the home directory (the file `~/.cargo/config`). The biggest problem with this is with options that can accept multiple values, like `build.rustflags`. If you parse the file twice, the same option can end with duplicated values (e.g: `rustflags=["-Z", "foo", "-Z", "foo"]`).
I made the fix following the comments in the issue. In the fix I keep track of all the parsed config files in a `HashSet` so I can know if a file has been parsed already. ~~I'm also using `std::fs::canonicalize`, as suggested in the issue, to prevent parsing files behind symbolic links more than once.~~
**UPDATE:** I removed the call to `fs::canonicalize` as suggested in the comments. Now the fix is way simpler, which means less code and less possibilities to add a new bug.
Juan Hernández [Fri, 9 Sep 2016 00:35:13 +0000 (20:35 -0400)]
Remove fs::canonicalize in walk_tree fix.
* Remove ConfiFile struct, it is not needed without the fs::canonicalize
call.
* Don't check if the file is in the stash when walking the tree,
without "canonicalization" it is not necessary.
Auto merge of #3072 - pietroalbini:fix-faq, r=steveklabnik
Remove reference of Rust 1.11.0 release date in the FAQ
In the `--frozen` section of the FAQ, there is a reference to the Rust 1.11.0 release date (probably because it was added in June), which is now in the past. In this pull request I removed that reference, since it's not useful anymore.
I also reflowed the text to 80 chars, to be consistent with the rest of the document :)
Auto merge of #3068 - binarybirchtree:generalize-error-message, r=alexcrichton
Generalize error message used by both `cargo package` and `cargo publish`.
Resolves issue #3061.
This pull request updates the wording of the error message in question to be applicable to both `cargo package` and `cargo publish`, and adds a test case for the example in the issue description.
Auto merge of #3060 - rillian:package_path_deps, r=alexcrichton
Reject path-based dependencies in `cargo package`
`cargo publish` will complain if a package manifest contains a path, rather than registry+version-based dependency. Make `cargo package` do the same so that issue is caught sooner in developer workflow.
Auto merge of #3063 - Wilfred:patch-1, r=alexcrichton
Clarify wording: this restriction is not just libraries
I found the previous wording a little confusing (see [discussion on users.rust-lang.org](https://users.rust-lang.org/t/uploading-binary-packages-not-libraries-to-crates-io/7072)).
Since the section heading specifically refers to libraries, I was puzzled that crates.io rejected my binary package with wildcard dependencies (plus a Cargo.lock file). I think this wording is clearer, let me know what you think.
Ideally we'd also say the reasoning behind rejecting wildcard dependencies for binary crates, but I don't know what the reasoning is.
Ralph Giles [Wed, 31 Aug 2016 23:11:33 +0000 (16:11 -0700)]
Check for path dependencies.
Port registry::verify_dependencies to the `cargo package`
command to perform the local portion of that check. It
looks like the package operation doesn't generally make
reference to the registry, so skip variant-origin checks
until publish time.
bors [Sun, 28 Aug 2016 19:02:39 +0000 (12:02 -0700)]
Auto merge of #3050 - nbaksalyar:configure-fix, r=alexcrichton
Fix POSIX shell in configure script (support Illumos & Solaris)
This patch provides the same fix that is applied for the `configure` script in rustc:
https://github.com/rust-lang/rust/blob/master/configure#L3-L9. It is required because `#!/bin/sh` is not Bash/POSIX-compatible on Solaris and its derivatives by default.
This change was previously discussed there: https://github.com/rust-lang/rust/pull/28589.
bors [Fri, 26 Aug 2016 19:48:17 +0000 (12:48 -0700)]
Auto merge of #3040 - matklad:rootless-readlockfile, r=alexcrichton
Don't use current package when reading lockfile
Looks like this `default` thing is basically a hack, which is fired when the lockfile references some package which is no longer present. That is, if I remove `default` and just `unwrap` source id, the only test which fails is `git_with_lockfile` because it has a typo in the lockfile.
So I've just changed the `default` to some dummy path. Perhaps a more correct solution would be to ignore such packages completely when loading lockfile.
bors [Tue, 23 Aug 2016 22:02:37 +0000 (15:02 -0700)]
Auto merge of #3021 - alexcrichton:test-release-panic-abort, r=brson
Fix transitive doctests panic=abort
Ensure that when we compile doctested libraries or examples we use the same
panic mode as the rest of the tests, namely ignoring panic=abort b/c libtest
isn't compiled with panic=abort.
bors [Mon, 22 Aug 2016 16:07:04 +0000 (09:07 -0700)]
Auto merge of #3029 - matklad:workspace-overrides, r=alexcrichton
Don't special case root package for overrides
Hi! What is the expected behavior of path overrides and workspaces? There are some [tests] for this, but looks like they don't actually test the behavior: this commit removes special casing of the root package, but `override_self` still passes. I see two options:
1. Allow overriding of the workspace members as usual. This amounts to removing that `filter`
2. Ignore overriding of the workspace members.
In any case, I think it would be nice to add a test which overrides local package to some other package to make sure that test does not pass simply because the package and its override are in fact the same.
bors [Sun, 21 Aug 2016 17:37:40 +0000 (10:37 -0700)]
Auto merge of #3026 - whitequark:patch-1, r=alexcrichton
doc: fix platform-specific definitions section
Right now the section seems to imply that using cfg(target_pointer_width = "32")
is an acceptable way to detect whether the crate should be built for x86.
bors [Fri, 19 Aug 2016 21:24:29 +0000 (14:24 -0700)]
Auto merge of #3022 - alexcrichton:add-more-metadata, r=brson
Add a temporary env var to enable hashes in filenames
For rustbuild we need the hashes to exist for all deps, even if they're path
deps, because we care about the actual file names. For example we don't want to
install /usr/lib/libstd.so!
This adds a "secret" environment variable, `__CARGO_DEFAULT_LIB_METADATA` which
re-enables the old behavior of just putting hashes in filenames.