bors [Thu, 7 Nov 2019 19:01:23 +0000 (19:01 +0000)]
Auto merge of #7565 - ehuss:expand-build-script-docs, r=alexcrichton
Expand documentation on build scripts.
This restructures and adds some more documentation for writing build scripts. An overview:
- Move examples to a separate chapter.
- Add some links to common build dependencies.
- Rewrote the example of linking to system libraries.
- Rewrote some of the `links` and `-sys` examples.
- Added a "conditional compilation" example.
- De-emphasize setting `build = "build.rs"`.
- Explain how build scripts run.
- Give each `cargo:` instruction a separate section with more detail.
- More detail on how `rerun-if` stuff works. Also, try to emphasize best practices, especially in examples.
- Try to clarify `links` and go into more detail.
- Document the jobserver.
- Expand on environment variables.
- Document dylib search path behavior.
I have explicitly skipped trying to document rpath issues, as it seems to be a mess, and I can't really sort it out.
I'd be happy to have any feedback for things to add or change.
bors [Thu, 7 Nov 2019 15:29:17 +0000 (15:29 +0000)]
Auto merge of #7566 - rust-lang:dependabot/cargo/crossbeam-utils-0.7, r=alexcrichton
Update crossbeam-utils requirement from 0.6 to 0.7
Updates the requirements on [crossbeam-utils](https://github.com/crossbeam-rs/crossbeam) to permit the latest version.
<details>
<summary>Changelog</summary>
*Sourced from [crossbeam-utils's changelog](https://github.com/crossbeam-rs/crossbeam/blob/master/CHANGELOG.md).*
> # Version 0.7.0
>
> - Remove `ArcCell`, `MsQueue`, and `TreiberStack`.
> - Change the interface of `ShardedLock` to match `RwLock`.
> - Add `SegQueue::len()`.
> - Rename `SegQueue::try_pop()` to `SegQueue::pop()`.
> - Change the return type of `SegQueue::pop()` to `Result`.
> - Introduce `ArrayQueue`.
> - Update dependencies.
>
> # Version 0.6.0
>
> - Update dependencies.
>
> # Version 0.5.0
>
> - Update `crossbeam-channel` to 0.3.
> - Update `crossbeam-utils` to 0.6.
> - Add `AtomicCell`, `SharedLock`, and `WaitGroup`.
>
> # Version 0.4.1
>
> - Fix a double-free bug in `MsQueue` and `SegQueue`.
>
> # Version 0.4
>
> - Switch to the new implementation of epoch-based reclamation in
> [`crossbeam-epoch`](https://github.com/crossbeam-rs/crossbeam-epoch), fixing numerous bugs in the
> old implementation. Its API is changed in a backward-incompatible way.
> - Switch to the new implementation of `CachePadded` and scoped thread in
> [`crossbeam-utils`](https://github.com/crossbeam-rs/crossbeam-utils). The scoped thread API is
> changed in a backward-incompatible way.
> - Switch to the new implementation of Chase-Lev deque in
> [`crossbeam-deque`](https://github.com/crossbeam-rs/crossbeam-deque). Its API is changed in a
> backward-incompatible way.
> - Export channel implemented in
> [`crossbeam-channel`](https://github.com/crossbeam-rs/crossbeam-channel).
> - Remove `AtomicOption`.
> - Implement `Default` and `From` traits.
>
> # Version 0.3
>
> - Introduced `ScopedThreadBuilder` with the ability to name threads and set stack size
> - `Worker` methods in the Chase-Lev deque don't require mutable access anymore
> - Fixed a bug when unblocking `pop()` in `MsQueue`
> - Implemented `Drop` for `MsQueue`, `SegQueue`, and `TreiberStack`
> - Implemented `Default` for `TreiberStack`
> - Added `is_empty` to `SegQueue`
> - Renamed `mem::epoch` to `epoch`
> - Other bug fixes
></tr></table> ... (truncated)
</details>
<details>
<summary>Commits</summary>
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Pull request limits (per update run and/or open at any time)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Update crossbeam-utils requirement from 0.6 to 0.7
Updates the requirements on [crossbeam-utils](https://github.com/crossbeam-rs/crossbeam) to permit the latest version.
- [Release notes](https://github.com/crossbeam-rs/crossbeam/releases)
- [Changelog](https://github.com/crossbeam-rs/crossbeam/blob/master/CHANGELOG.md)
- [Commits](https://github.com/crossbeam-rs/crossbeam/compare/crossbeam-utils-0.6.0...crossbeam-utils-0.7.0)
bors [Mon, 28 Oct 2019 21:53:41 +0000 (21:53 +0000)]
Auto merge of #7376 - ehuss:filter-platform, r=alexcrichton
Add --filter-platform to `cargo metadata`.
This adds the `--filter-platform` flag to `cargo metadata` to give users a way to filter the resolve information based on the target triple.
This is just a prototype to open for feedback. Some things that need feedback:
- Debate the name of the flag.
- It uses "host" as a special triple to mean the local host. Does that make sense? It seemed a little weird.
- Should it also filter the dependencies in the "packages" array? Right now it only does resolve. I'm on the fence. It probably should, but that would be an intrusive change to rewrite the Package values.
- Should the filtering be transitive? That is, if a package is only reachable by a specific platform, should it be removed from the resolve "nodes"? What about "packages"? Currently it is included, with the intent that you walk the resolve starting with a root (like a workspace member). But it might be surprising to see "winapi" when you filter for a unix platform.
bors [Mon, 28 Oct 2019 19:57:57 +0000 (19:57 +0000)]
Auto merge of #7550 - ehuss:fix-color, r=alexcrichton
Fix `cargo fix` not showing colors.
`cargo fix` runs `rustc` a final time after it has finished to:
- Show what happened if the fix failed.
- Show errors with `--broken-code`.
- Show any remaining warnings after a successful fix.
This last run was no longer showing colored diagnostics due to the stabilization of cache-messages. Cargo now unconditionally uses colored JSON messages, and then conditionally strips them after the fact. "cargo as rustc wrapper" was stripping the JSON flags which allowed Cargo to handle colors.
This fix works by putting the json flags back in for this final pass.
bors [Thu, 24 Oct 2019 20:33:33 +0000 (20:33 +0000)]
Auto merge of #7536 - ehuss:profile-override-warning-fix, r=alexcrichton
Fix profile override warning in a workspace.
Profile overrides would erroneously warn about unused packages in a workspace if the package was not being built. The fix here is to retain the `Resolve` for the entire workspace, and use that to determine the valid set of packages.
I think it would be good for a long-term goal to get rid of the second ("targeted") resolve. I'm still contemplating how a separate features resolver could achieve that, but it seems feasible long-term.
bors [Thu, 24 Oct 2019 19:48:28 +0000 (19:48 +0000)]
Auto merge of #7535 - ehuss:better-windows-errors, r=alexcrichton
Show better error message for Windows abnormal termination.
This helps display better error messages when there is an abnormal termination on Windows.
If rustc crashes, there was a slight mistake in #6270, where the error code was actually negative, so the message was getting hidden behind the `--verbose` flag. This changes it show that the abnormal error is always shown if rustc crashes in an unusual way.
This also changes `cargo test` to display a better message if the test crashes. Previously:
```
running 1 test
error: test failed, to rerun pass '--bin crash'
```
New:
```
running 1 test
error: test failed, to rerun pass '--bin crash'
I didn't add any tests because testing on this on Windows seems a little precarious. AFAIK, the exact error message depends on the processor (like x86 vs i686), and Windows version. I was concerned about chasing down every little nuance, though I'm willing to try if it seems important.
bors [Tue, 22 Oct 2019 14:18:30 +0000 (14:18 +0000)]
Auto merge of #7531 - ehuss:z-flag-parsing, r=alexcrichton
Use stricter -Z flag parsing.
This makes sure that toggle flags don't have any arguments (like `-Zno-index-update=foo`). It also provides slightly better error messages, like indicating which flag failed.
bors [Mon, 21 Oct 2019 17:59:52 +0000 (17:59 +0000)]
Auto merge of #7523 - bruceg:fix-zero-timestamps, r=alexcrichton
Set timestamp on generated files in archive to now
When generating files (Cargo.lock, Cargo.toml, and
.cargo_vcs_info.json), cargo neglected to set any timestamp on the file
in the archive. This results in them being created on disk with a
timestamp of 0 (Jan 1 1970 GMT) which is confusing another tool I use.
This patch alters the behavior to set the mtime to now.
Signed-off-by: Bruce Guenter <bruce@untroubled.org>
bors [Mon, 21 Oct 2019 16:37:34 +0000 (16:37 +0000)]
Auto merge of #7460 - alexcrichton:panic-abort-tests, r=ehuss
Support rustc's `-Z panic-abort-tests` in Cargo
Recently added in rust-lang/rust#64158 the `-Z panic-abort-tests` flag
to the compiler itself will activate a mode in the `test` crate which
enables running tests even if they're compiled with `panic=abort`. It
effectively runs a test-per-process.
This commit brings the same support to Cargo, adding a `-Z
panic-abort-tests` flag to Cargo which allows building tests in
`panic=abort` mode. While I wanted to be sure to add support for this in
Cargo before we stabilize the flag in `rustc`, I don't actually know how
we're going to stabilize this here. Today Cargo will automatically
switch test targets to `panic=unwind`, and so if we actually were to
stabilize this flag then this configuration would break:
[profile.dev]
panic = 'abort'
In that case tests would be compiled with `panic=unwind` (due to how
profiles work today) which would clash with crates also being compiled
with `panic=abort`. I'm hopeful though that we can perhaps either figure
out a solution for this and maybe even integrate it with the ongoing
profiles work.
Alex Crichton [Mon, 30 Sep 2019 15:48:43 +0000 (08:48 -0700)]
Support rustc's `-Z panic-abort-tests` in Cargo
Recently added in rust-lang/rust#64158 the `-Z panic-abort-tests` flag
to the compiler itself will activate a mode in the `test` crate which
enables running tests even if they're compiled with `panic=abort`. It
effectively runs a test-per-process.
This commit brings the same support to Cargo, adding a `-Z
panic-abort-tests` flag to Cargo which allows building tests in
`panic=abort` mode. While I wanted to be sure to add support for this in
Cargo before we stabilize the flag in `rustc`, I don't actually know how
we're going to stabilize this here. Today Cargo will automatically
switch test targets to `panic=unwind`, and so if we actually were to
stabilize this flag then this configuration would break:
[profile.dev]
panic = 'abort'
In that case tests would be compiled with `panic=unwind` (due to how
profiles work today) which would clash with crates also being compiled
with `panic=abort`. I'm hopeful though that we can perhaps either figure
out a solution for this and maybe even integrate it with the ongoing
profiles work.
bors [Fri, 18 Oct 2019 22:20:14 +0000 (22:20 +0000)]
Auto merge of #7526 - ehuss:rustfmt, r=alexcrichton
rustfmt for nightly changes.
Something in the latest nightly versions of rustfmt has slightly changed the logic here. Fortunately stable ignores the new formatting, and it looks better to me anyways. I tend to always use nightly, so this helps me with a slight annoyance where this line keeps getting changed.
bors [Fri, 18 Oct 2019 17:07:21 +0000 (17:07 +0000)]
Auto merge of #7525 - ehuss:allow-all-features-virtual-ws, r=alexcrichton
Allow --all-features in root of virtual workspace.
Accidentally restricted in #7507, pointed out by @hjmallon, `--all-features` flag is allowed in the root of a virtual workspace. Added a test to demonstrate its strange behavior.
For anyone that is curious, [this line](https://github.com/rust-lang/cargo/blob/3a9abe3f065554a7fbc59f440df2baba4a6e47ee/src/cargo/ops/resolve.rs#L302) is the code responsible for this behavior.
Bruce Guenter [Thu, 17 Oct 2019 21:40:05 +0000 (15:40 -0600)]
Set timestamp on generated files in archive to now
When generating files (Cargo.lock, Cargo.toml, and
.cargo_vcs_info.json), cargo neglected to set any timestamp on the file
in the archive. This results in them being created on disk with a
timestamp of 0 (Jan 1 1970 GMT) which is confusing another tool I use.
This patch alters the behavior to set the mtime to now.
Signed-off-by: Bruce Guenter <bruce@untroubled.org>
bors [Tue, 15 Oct 2019 15:26:07 +0000 (15:26 +0000)]
Auto merge of #7507 - ehuss:virtual-ws-features, r=alexcrichton
Reject feature flags in a virtual workspace.
This generates an error if feature flags are used in the root of a virtual workspace. Previously these flags were completely ignored. In the interest of avoiding confusion, I think it would be good to be explicit that these don't currently work. This could alternatively be a warning, but I think it is better to reject it outright.
bors [Tue, 15 Oct 2019 14:38:29 +0000 (14:38 +0000)]
Auto merge of #7333 - ehuss:allow-dev-dep-path, r=alexcrichton
Allow publishing with dev-dependencies without a version.
This change allows dev-dependencies without a `version` key to be published. If a dev-dependency is missing the `version`, it will be stripped from the packaged manifest.
bors [Tue, 15 Oct 2019 13:48:13 +0000 (13:48 +0000)]
Auto merge of #7450 - ehuss:stabilize-cache-messages, r=alexcrichton
Stabilize cache-messages
This stabilizes the -Zcache-messages feature, making it always enabled.
## What is stabilized?
This feature is intended to redisplay previous warnings on a "fresh" build instead of displaying no output.
Users have occasionally indicated frustration when they know there are warnings, but no output is displayed when the build is fresh. This also improves the interaction between `cargo check` and `cargo clippy-preview`. This also simplifies the code, and opens more possibilities for `rustc` to send side-channel messages to Cargo.
Cargo will now use JSON output from `rustc` and `rustdoc` 100% of the time (`rustdoc --test` does not use JSON). Previously Cargo would only use JSON for pipelined crates.
Cargo will save the JSON output into a file named `output` in the `.fingerprint` directory. This file is only created when the compiler outputs a diagnostic message.
If a crate is being recompiled, and Cargo considers it to be "fresh", it will replay the output file to the console.
## Notable changes in this PR
- Fixed a bug where replays were erroneously including pipeline rmeta artifact json messages.
- clippy-preview is now included in the metadata hash, to force its artifacts to be separate from `cargo check`.
- clippy-preview is no longer force-enabled, under the assumption that caching and fingerprinting is accurate, and the cached messages will be replayed.
- clippy-preview's arguments are included in the fingerprint now that it is not force-enabled.
- Rustdoc colors and short messages were fixed when pipelining was stabilized, so updated tests.
The only notable issue with this is that switching between short and long human messages only replays the format from the first invocation. That is, if you do `cargo build` and it generates warnings, then running again with `--message-format=short` will still show the full length human messages. I'm personally fine with that behavior, even though it is not ideal. I think this feature overall improves the situation (where before *no* output was displayed). Being able to re-render between short/long is a very difficult problem, and unlikely to be fixable in the foreseeable future.
There was some concern expressed about being able to disable this. I think that would only be necessary if a severe bug is discovered. I do not feel that this change is risky enough to warrant a configurable option. If it does cause a problem, it can be quickly reverted with a one-line change to set `OutputOptions::cache_cell` to `None`. Since pipelining has been using JSON output for a while now without complaints, I feel pretty confident in it.
bors [Wed, 9 Oct 2019 16:55:15 +0000 (16:55 +0000)]
Auto merge of #7456 - alexcrichton:config-only-serde, r=ehuss
Migrate towards exclusively using serde for `Config`
This series of commits was spawned off a thought I had while reading https://github.com/rust-lang/cargo/issues/7253#issuecomment-535656059, although it ended up not really touching on that at all. I was a little unsettled about how unstructured the config accesses are throughout Cargo and we had sort of two systems (one serde which is nice, one which is more manual) for reading config values.
This PR converts everything to run through serde for deserializing values, except for `get_list` which is funky. There's only one usage of that with the `paths` key though and we can probably fix this soon-ish.
In any case, the highlights of this PR are:
* This PR is surprisingly large. I did a lot of movement in `config.rs` to try to make the file smaller and more understandable.
* The `Value` type which retains information about where it was deserialized from is very special, and has special treatment with serde's data model. That's what allows us to use that and serde at the same time.
* The `ConfigRelativePath` and `ConfigKey` structures have been revamped internally, but morally serve the same purposes as before.
* Cargo now has structured `struct` access for a bunch of its configuration (`net`, `http`, `build`, etc). I would ideally like to move toward a world where this is the *only* way to read configuration, or at least everything conventionally runs through those paths.
* Functionally, this PR should have no difference other than tweaks to error messages here and there, and perhaps more strict validation on commands where we validate more configuration on each run than we previously did.
* This isn't a 100% transition for Cargo yet, but I figured it would be a good idea to post this and get some feedback first.
* In the long run I want to remove `get_env`, `get_cv`, and `get_*_priv` from `Config` as internal details. I'd like to move this all to `de.rs` and have it walk down the tree of configuration as we deserialize a value. For now though these all remain in place and that refactoring is left to a future PR.
bors [Tue, 8 Oct 2019 01:16:07 +0000 (01:16 +0000)]
Auto merge of #7470 - alexcrichton:cyclic-error, r=Eh2406
Improve error message for cyclic dependencies
First reported in rust-lang/rust#65014 it looks like our error message
on cyclic dependencies may be confusing at times. It looks like this is
an issue because there are multiple paths through a graph for a
dependency, so using the generic `path_to_top` function isn't producing
the most useful path for this purpose.
We're already walking the graph though, so this commit adds an extra
parameter which collects the list of packages we've visited so far to
produce a hopefully always-accurate error message showing the chain of
dependencies end-to-end for what depends on what.
Alex Crichton [Fri, 27 Sep 2019 19:29:01 +0000 (12:29 -0700)]
Finish implementing `Value`, use it in helpers
Rewrite helpers like `get_bool` to use `get::<Option<Value<bool>>>`
instead of duplicating the logic that's already with the typed access of
configuration. This is more along the effort to centralize all
deserialization of configuration into typed values instead of using
ad-hoc accessors in a number of locations.
Alex Crichton [Fri, 27 Sep 2019 18:34:29 +0000 (11:34 -0700)]
Refactor `ConfigKey` to its own file
Also make it a little less allocation-heavy by tweaking the API to
encourage incremental building of the key and incremental destruction as
we walk throughout the configuration tree.
Alex Crichton [Wed, 2 Oct 2019 20:42:42 +0000 (13:42 -0700)]
Improve error message for cyclic dependencies
First reported in rust-lang/rust#65014 it looks like our error message
on cyclic dependencies may be confusing at times. It looks like this is
an issue because there are multiple paths through a graph for a
dependency, so using the generic `path_to_top` function isn't producing
the most useful path for this purpose.
We're already walking the graph though, so this commit adds an extra
parameter which collects the list of packages we've visited so far to
produce a hopefully always-accurate error message showing the chain of
dependencies end-to-end for what depends on what.
projects / cargo.git / log