bors [Sat, 14 Oct 2017 14:54:15 +0000 (14:54 +0000)]
Auto merge of #4616 - kennytm:fix-4490, r=alexcrichton
Uplift *.dSYM
Fixed #4490.
The solution is based on #4570. Simply adding `.dSYM` into `add_target_specific_suffixes` will cause cargo trying to actually run that `.dSYM` folder, so I've upgraded the `linkable` boolean into a 3-value enum `TargetFileType`, to tell `cargo run` and `cargo test` to avoid these debug symbol files.
(I haven't checked if it can solve #4056, don't wanna mess with Spotlight 😝)
bors [Thu, 12 Oct 2017 08:52:44 +0000 (08:52 +0000)]
Auto merge of #4314 - nodakai:phantom-type-in-projectbuilder, r=matklad
cargotest/support: remove internal mutability in favor of switching types
`Cell<bool>` was removed from `ProjectBuilder`. Instead `PhantomData<T>` was added to it (and `RepoBuilder`) to manage state transition in the type level (`T` is either `Configuring` or `Done`.)
`ProjectBuilder::cargo_process()` was removed as its design heavily depended on the internal mutability.
Also added `#[must_use]` to `ProjectBuilder` and `RepoBuilder` to check for call sites of their `build()` method.
bors [Tue, 10 Oct 2017 19:20:43 +0000 (19:20 +0000)]
Auto merge of #4594 - behnam:workspace, r=alexcrichton
[core/workspace] Create WorkspaceRootConfig
Create `WorkspaceRootConfig`, which knows its `root_dir` and lists of
`members` and `excludes`, to answer queries on which paths are a member
and which are not.
----
This is the first step of the fix, that's only a codemod to put together the relevant parts : `workspace.members`, `workspace.excludes`, and the `root_dir` (where `members` and `excludes` are relative to). There's no logic change in this PR to keep review easier.
The added tests are commented out, because they fail with the current logic. The next step to get these steps to pass.
Tracker: <https://github.com/rust-lang/cargo/issues/4089>
Old PR: <https://github.com/rust-lang/cargo/pull/4297>
bors [Tue, 10 Oct 2017 18:36:48 +0000 (18:36 +0000)]
Auto merge of #4581 - tamird:master, r=alexcrichton
cargo_rustc: remove workaround for fixed upstream issue
Fixed in https://github.com/rust-lang/rust/pull/25411. Also, the
removed code is implicated in test failures observed in
https://github.com/rust-lang/rust/pull/44515.
bors [Tue, 10 Oct 2017 17:58:30 +0000 (17:58 +0000)]
Auto merge of #4602 - ehuss:fix-new-test-windows, r=alexcrichton
Allow test to pass if user has ~/.gitconfig on Windows.
The `new` test will fail on Windows if you have `~/.gitconfig` configured with a username/email. This is because libgit2 searches quite a few environment variables hunting for a config file. Rather than adjusting other environment variables (I think at a minimum it would be `%HOMEDRIVE%%HOMEPATH%` and `%USERPROFILE%`), this just adds an empty config file since libgit2 will stop at the first one it finds.
cargo_rustc: remove workaround for fixed upstream issue
Fixed in https://github.com/rust-lang/rust/pull/25411. Also, the
removed code is implicated in test failures observed in
https://github.com/rust-lang/rust/pull/44515.
bors [Mon, 9 Oct 2017 20:48:17 +0000 (20:48 +0000)]
Auto merge of #4570 - tatsuya6502:target-specific-artifacts, r=alexcrichton
Handle target specific outputs such as .wasm or .dll.lib
Fixes #4500, #4535
Until now, Cargo does not have any knowledge about target-specific output files. It relies solely on rustc for this sort of information (`rustc --print=file-names ...`).
As a result, Cargo does not place some build artifacts (files) to target/{debug,release} directory. These files include *.wasm for wasm32-unknown-emscripten target and *.dll.lib for *-pc-windows-msvc cdylib target.
This commit will add such knowledge to Cargo so that *.wasm and *.dll.lib will be placed in target/{debug,release} directory.
**EDIT**: I added [a summary of changes](https://github.com/rust-lang/cargo/pull/4570#issuecomment-334433635). Please read it for more details of changes.
**IMPORTANT**
Although I added test cases for both wasm32-unknown-emscripten and *-pc-windows-msvc cdylib targets, ~I did not do manual testing on wasm32-unknown-emscripten target as I do not have an environment with emscripten installed. It will be appreciated if anybody tests this change for wasm32-unknown-emscripten target.~ **EDIT**: Tested for both wasm32-unknown-emscripten and x86_64-pc-windows-msvc. Thanks @Herschel for the help.
bors [Sun, 8 Oct 2017 02:32:33 +0000 (02:32 +0000)]
Auto merge of #4595 - treiff:update-appveyor-badge-documentation, r=alexcrichton
Update docs for appveyor badge.
Can now optionally specify the appveyor `project_name`.
Related PR: [rust-lang/crates.io#1111](https://github.com/rust-lang/crates.io/pull/1111)
Related Issue: [rust-lang/crates.io#587](https://github.com/rust-lang/crates.io/issues/587)
Create `WorkspaceRootConfig`, which knows its `root_dir` and lists of
`members` and `excludes`, to answer queries on which paths are a member
and which are not.
bors [Sat, 7 Oct 2017 15:09:06 +0000 (15:09 +0000)]
Auto merge of #4578 - derekdreery:refactor/cargo_util_config, r=alexcrichton
Remove some cells from Config
In most cases it makes sense to not use interior mutability in Config, so that mutability is more transparent. This PR removes Cells in these cases. It leaves those cases where parameters are only initialized on first access (LazyCell).
bors [Fri, 6 Oct 2017 17:54:30 +0000 (17:54 +0000)]
Auto merge of #4586 - lukaslueg:issue4534, r=alexcrichton
Report hint if single failure with --no-fail-fast
There are two things going on in #4534:
* The doctest-kind masks the unittest-kind if doctests are executed during `--no-fail-fast`, no doctests fail and tests errors have already piled up. This is bug, fixed.
* Cargo would previously not report any unittest-hints if running with `--no-fail-fast`. This behavior has been changed to report a specific hint iif exactly one error has bubbled up during `--no-fail-fast`. The hint in #4534 is now `...pass '--test integ'`.
bors [Thu, 5 Oct 2017 22:54:59 +0000 (22:54 +0000)]
Auto merge of #4583 - alexcrichton:unstable, r=matklad
Fix [patch] causing updates with a virtual manifest
This commit fixes the [patch] implementation to avoid causing spurious updates
of the registry when specified inside of a virtual manifest via a path
dependency that was otherwise outside of the workspace.
Cargo previously attempted to learn about path dependencies through the
configuration of the workspace by looking at members, their path dependencies,
and their replace sections. The replace/patch sections, however, only matter at
the root of the workspace and those weren't looked at! This commit fixes this
problem by explicitly looking at the workspace's replace/patch sections and
avoiding looking at other manifest replace/patch which shouldn't matter.
Alex Crichton [Thu, 5 Oct 2017 22:11:25 +0000 (15:11 -0700)]
Fix [patch] causing updates with a virtual manifest
This commit fixes the [patch] implementation to avoid causing spurious updates
of the registry when specified inside of a virtual manifest via a path
dependency that was otherwise outside of the workspace.
Cargo previously attempted to learn about path dependencies through the
configuration of the workspace by looking at members, their path dependencies,
and their replace sections. The replace/patch sections, however, only matter at
the root of the workspace and those weren't looked at! This commit fixes this
problem by explicitly looking at the workspace's replace/patch sections and
avoiding looking at other manifest replace/patch which shouldn't matter.
Tatsuya Kawano [Thu, 5 Oct 2017 01:37:04 +0000 (09:37 +0800)]
Handle target specific outputs such as .wasm
Fixes #4535
- Do not add metadata to wasm32 bin target because generated .js will
refer corresponding .wasm.
- Handle different usages of "-" and "_" in .js and .wasm file names.
(e.g "foo-bar.js" vs. "foo_bar.wasm")
- Change file mode of cargo_rustc/context.rs (100755 -> 100644)
bors [Wed, 4 Oct 2017 18:30:20 +0000 (18:30 +0000)]
Auto merge of #4571 - raytung:remove-root-from-cargo-lock, r=matklad
Remove root from cargo lock
Removing [root] section from Cargo.lock for #4563
Tests of interest has been updated accordingly, especially [tests/lockfile-compat.rs#oldest_lockfile_still_works](https://github.com/rust-lang/cargo/compare/master...raytung:remove-root-from-cargo-lock?expand=1#diff-48866d1891f97cb799dd0ca7148d1eefR10)
Tatsuya Kawano [Tue, 3 Oct 2017 11:44:35 +0000 (19:44 +0800)]
Handle target specific outputs such as .wasm or .dll.lib
Fixes #4500, #4535
Until now, Cargo does not have any knowledge about target-specific
output files. It relies solely on rustc for this sort of information
(`rustc --print=file-names ...`).
As a result, Cargo does not place some build artifacts (files) to
target/{debug,release} directory. These files include *.wasm
for wasm32-unknown-emscripten target and *.dll.lib for
*-pc-windows-msvc cdylib target.
This commit will add such knowledge to Cargo so that *.wasm and
*.dll.lib will be placed in target/{debug,release} directory.
bors [Mon, 2 Oct 2017 10:40:21 +0000 (10:40 +0000)]
Auto merge of #4562 - SimonSapin:btree-manifest, r=matklad
Make manifest serialization deterministic
Fixes #4326
`cargo package` (and so `cargo publish`) parses a crate’s `Cargo.toml`, makes some modifications, and re-serializes it. Because the `TomlManifest` struct uses `HashMap` with its default `RandomState` hasher, the maps’ iteration order changed on every run.
As a result, when using `cargo vendor`, updating a dependency would generate a diff larger than necessary, with non-significant order-changes obscuring significant changes.
This replaces some uses of `HashMap` with `BTreeMap`, whose iteration order is deterministic (based on `Ord`).
Simon Sapin [Mon, 2 Oct 2017 10:04:02 +0000 (12:04 +0200)]
Make manifest serialization deterministic
Fixes #4326
`cargo package` (and so `cargo publish`) parses a crate’s `Cargo.toml`,
makes some modifications, and re-serializes it.
Because the `TomlManifest` struct uses `HashMap`
with its default `RandomState` hasher,
the maps’ iteration order changed on every run.
As a result, when using `cargo vendor`,
updating a dependency would generate a diff larger than necessary,
with non-significant order-changes obscuring significant changes.
This replaces some uses of `HashMap` with `BTreeMap`,
whose iteration order is deterministic (based on `Ord`).
Auto merge of #4550 - lukaslueg:issue4539, r=alexcrichton
Improve error ico doc-targets with same name
Replace the `assert!` that was triggered in #4539 with a `bail!`, giving the user a clear error that points to the offending packages. The error message now looks like
> The binary `foo_cli` is specified by packages `foo (file://...)` and `bar (file://...)` but can be documented only once. Consider renaming or marking one of the targets as `doc = false`.
or
> The library `foo_cli` is specified by packages `foo (file://...)` and `bar (file://...)` ...
or
> The target `foo_cli` is specified as a library and as a binary by package `foo (file://...)`. It can be documented only once. Consider...
or
> The target `foo_cli` is specified as a library by package `foo (file://...)` and as a binary by package `bar (file://...)`. It can be ...
Add unit-test for all cases, including one that ensures the advertised mitigation `doc = false` actually works.
Auto merge of #4551 - natboehm:owner-invite-messages, r=alexcrichton
Owner invite messages
This PR addresses issue #4537, the plan for `cargo owner --add` requiring invitations in Cargo and the encompassing issue [#924](https://github.com/rust-lang/crates.io/issues/924), requiring an invite to add someone as an owner in Crates.io.
Regarding the Cargo issue, we went with Option 2, changing the `add_owners` function to decode a struct sent from Crates containing a `boolean` and `String`, the `boolean` being the response status and `String` being the success message. This may sound redundant however we concluded that using both of these fields were necessary to support older versions of Cargo - if we changed Crates.io to only return the `String` message on success this would likely break systems using the older version of `add_owner` expecting a response containing a `boolean`. Matching this schema, `add_owners` on the Crates.io side will soon return a struct containing a `boolean` and `String`, and instead of adding a new crate owner to the database will add a crate owner invite. If successful, `modify_owners` now prints the message sent from Crates.io instead of the old hardcoded message.
Auto merge of #4547 - lukaslueg:installlisterror, r=alexcrichton
Improve error message for crippled .crates.toml
In case `.crates.toml` can't be parsed for some reason, the user is left wondering where to look. The problem is exasperated by the fact that `.cargo.toml` is a hidden file. Improve the error message during `install`/`uninstall`/`list` and point to the path of `.crates.toml`. A error message might now look like
> error: failed to parse crate metadata at `/home/foobar/.cargo/.crates.toml`
>
> Caused by:
> invalid TOML found for metadata
>
> Caused by:
> ...
A unit-test for a crippled `.cargo.toml` had been missing before, added that.
Auto merge of #4542 - equal-l2:sha256-crypto-hash, r=alexcrichton
Use crypto-hash to calculate SHA256
`crypto-hash` is an abstraction library for native hash libraries.
It uses CryptoAPI on Windows, CommonCrypto on macOS, and OpenSSL on *nix.
This PR will also remove `openssl` and `advapi32-sys` from dependencies since they are only used for calculating SHA256, which is superseded by `crypto-hash`.
(`crypto-hash` itself uses `openssl` and `advapi32-sys` though)
Auto merge of #4530 - djc:update-deps, r=alexcrichton
Update dependencies
It would be nice to use openssl-0.9.19 in particular, since it supports
newer LibreSSL.
Not sure how this usually works, would it be better to only update openssl and related dependencies? I figured doing everything at once couldn't hurt, and it seems to pass tests locally at least.
Also, would it be feasible to backport this to the beta branch?
Auto merge of #4526 - lukaslueg:patch-2, r=matklad
Update CONTRIBUTING.md
Point out that code added to Cargo may raise the minimal version of Rust required. Cargo does not have a grace period where it has to compile on "stable -2" or anything like that.