Auto merge of #7452 - pyrrho:bug7346/transitive_patches, r=Eh2406
Bug7346/transitive patches
Fixes #7346.
A cursory comparison between current stable and nightly shows that projects with this topology resolve similarly. If there are other behaviors I should test, I'd be happy to expand that section. This is a pretty focused change, though, so I'm not sure what else there is to break.
Sorry about the delay in putting this PR together. Good news is I know more than I did last week.
Auto merge of #7448 - ehuss:gitignore-lockfile, r=alexcrichton
Allow gitignore of Cargo.lock with explicit `include`.
If a package has an `include` list, but `Cargo.lock` is in `.gitignore`, then Cargo would complain that `Cargo.lock` is "dirty". This changes it so that ignored `Cargo.lock` is allowed, even though it is still packaged. This is under the presumption that `Cargo.lock` is machine generated, so it is not critical. This was also an unexpected regression.
If you don't have an `include` list, then there is no complaint about `Cargo.lock` being dirty because Cargo uses git to deduce the file list, and `Cargo.lock` would be skipped for the dirty check (but still included in the package).
Auto merge of #7446 - alexcrichton:quiet-output, r=Eh2406
Improve test output with `--quiet`
We had a few locations where the shell was written to raw instead of
through the test harness or through other captured mechanisms. This
updates the test suite so testing Cargo with `--quiet` provides a nice
and clean report of tests executed.
Alex Crichton [Thu, 26 Sep 2019 18:21:54 +0000 (11:21 -0700)]
Improve test output with `--quiet`
We had a few locations where the shell was written to raw instead of
through the test harness or through other captured mechanisms. This
updates the test suite so testing Cargo with `--quiet` provides a nice
and clean report of tests executed.
Auto merge of #7425 - alexcrichton:kind-string, r=ehuss
Refactor `Kind` to carry target name in `Target`
This commit is an internal refactoring of Cargo's compilation backend to
eventually support compiling multiple target simultaneously. The
original motivation for this came up in discussion of #7297 and this has
long been something I've intended to update Cargo for. Nothing in the
backend currently exposes the ability to actually build multiple target
simultaneously, but this should have no function change with respect to
all current consumers. Eventually we'll need to refactor APIs of how you
enter the compilation backend to compile for multiple targets.
Alex Crichton [Wed, 25 Sep 2019 15:14:20 +0000 (08:14 -0700)]
Refactor how compile targets are handled
Rename `Kind` to `CompileKind` to reflect that it's intended for
compilation. Additionally change the `Target` variant to have a newtype
`CompileTarget` instead of just being a raw string. This new
`CompileTarget` type has a fallible constructor and handles custom json
target files internally.
Two accessors are available for `CompileTarget`, one is `rustc_target()`
which goes straight to rustc and everything else uses `short_name()`
which is the raw target or file stem for json files. The `short_name` is
used everywhere in Cargo for all purposes like configuration, env vars,
target directory naming, etc.
Alex Crichton [Tue, 24 Sep 2019 17:53:32 +0000 (10:53 -0700)]
Refactor `Kind` to carry target name in `Target`
This commit is an internal refactoring of Cargo's compilation backend to
eventually support compiling multiple target simultaneously. The
original motivation for this came up in discussion of #7297 and this has
long been something I've intended to update Cargo for. Nothing in the
backend currently exposes the ability to actually build multiple target
simultaneously, but this should have no function change with respect to
all current consumers. Eventually we'll need to refactor APIs of how you
enter the compilation backend to compile for multiple targets.
Auto merge of #7429 - alexcrichton:fix-osx-cpu, r=ehuss
Fix macOS collection of CPU data
There's very little documentation on `host_processor_info` from what I can tell, so I'm just cribbing examples I've found elsewhere on the internet. Turns out two things were wrong:
* One is that `host_processor_info` returns allocated memory we need to deallocate. Who knew!
* Next is that one of the out parameters, `cpu_info_cnt`, is only somehow related to the size of the return, but all example code appears to just read data regardless of what it is.
In any case this commit reads [libuv's implementation](https://github.com/libuv/libuv/blob/040543eebf4983b1459a1e0e0e26dae68b80cc28/src/unix/darwin.c#L174-L225) which if good enough for node.js is probably good enough for us.
Auto merge of #7421 - ehuss:build-std-sysroot, r=alexcrichton
Change build-std to use --sysroot
This transitions build-std to use `--sysroot` instead of `--extern`. This is necessary because existing crates have a certain expectation of how standard library crates are exposed. It was intended that explicit dependencies in `Cargo.toml` would solve this problem, but I didn't really consider this would be a backwards-incompatible change, so using `--sysroot` is probably the best way to go, even though it's not ideal.
Alex Crichton [Wed, 25 Sep 2019 15:37:55 +0000 (08:37 -0700)]
Fix a panic collecting cpu data on OSX
There's very little documentation on `host_processor_info` from what I
can tell, so I'm just cribbing examples I've found elsewhere on the
internet. It appears that I've misinterpreted one of the out parameters
of `host_processor_info` as the number of elements of an array, but it
actually is just something forwarded to `vm_deallocate`.
Alex Crichton [Wed, 25 Sep 2019 15:29:42 +0000 (08:29 -0700)]
Call `vm_deallocate` on OSX for CPU statistics
Apparently StackOverflow doesn't have all the answers. The examples
there I lifted this from didn't account to call `vm_deallocate` because
it looks like we're handed allocated memory! Indeed running the previous
state capture in a loop it infinitely allocated memory, but now it holds
steady when called in a loop.
Auto merge of #7411 - Eh2406:mtime, r=alexcrichton
set -Zmtime_on_use from config or ENV
This lets you set the `-Zmtime_on_use` in config, it worked for me with
```toml
[unstable]
mtime_on_use=true
```
I did not find the ENV that would allow work. Suggestions?
Does this need tests?
Auto merge of #7422 - rust-lang:dependabot/cargo/env_logger-0.7.0, r=Eh2406
Update env_logger requirement from 0.6.0 to 0.7.0
Updates the requirements on [env_logger](https://github.com/sebasmagri/env_logger) to permit the latest version.
<details>
<summary>Release notes</summary>
*Sourced from [env_logger's releases](https://github.com/sebasmagri/env_logger/releases).*
> ## 0.7.0
> # Key Changes
>
> - Indent multiline messages by default
> - Support more timestamp precision
> - Update to the 2018 edition
>
> # Changes to minimum Rust
>
> The minimum version of Rust required has been set at `1.31.0`. We may change this in patch versions, but will always flag it in the release notes here.
>
> You can always check the `.travis.yml` file to see the current minimum supported version.
>
> # Contributions
>
> - [@​95ulisse](https://github.com/95ulisse) [Indentation for multiline log messages](https://github-redirect.dependabot.com/sebasmagri/env_logger/pull/134)
> - [@​oherrala](https://github.com/oherrala) [Add more timestamp precisions](https://github-redirect.dependabot.com/sebasmagri/env_logger/pull/140)
> - [Update to 2018 edition](https://github-redirect.dependabot.com/sebasmagri/env_logger/pull/142)
</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)
Finally, you can contact us by mentioning @dependabot.
Updates the requirements on [env_logger](https://github.com/sebasmagri/env_logger) to permit the latest version.
- [Release notes](https://github.com/sebasmagri/env_logger/releases)
- [Changelog](https://github.com/sebasmagri/env_logger/blob/master/CHANGELOG.md)
- [Commits](https://github.com/sebasmagri/env_logger/compare/v0.6.0...v0.7.0)
Alex Crichton [Mon, 23 Sep 2019 19:07:24 +0000 (12:07 -0700)]
Change how standard_lib tests work
* Minimize the sysroot crates in play
* Don't use build scripts to inject args
* Use `RUSTC_WRAPPER` to dynamically switch `--sysroot` depending on
whether we're building sysroot crates or not.
* Minimize dependency graph in sysroot, only have each crate depend on a
dummy crates.io crate for testing and otherwise don't depend on
anything to load the desired sysroot crate directly.
Auto merge of #7408 - ehuss:fix-xcompile-tests, r=alexcrichton
Fix xcompile tests.
The new xcompile tests weren't checking whether or not cross-compiling is disabled. Cross doesn't work on modern macos/xcode, so these were failing for me.
Auto merge of #7397 - ehuss:fix-timing-scale, r=alexcrichton
Fix some rendering issues with -Ztimings.
- Cap the max width to 4096. This is still quite large, but should help for some large graphs failing to display for using too much memory.
- Don't allow labels to overflow past the right side of the graph.
- Fix issue for very fast builds causing an error because there aren't enough CPU_USAGE entries.
- Fix bug where `split_ticks` would enter an infinite loop (caused by small scale values). Added a counter to abort in case there are any other bugs.
Auto merge of #7395 - ehuss:fix-timings-test, r=alexcrichton
Fix -Ztimings with doc tests.
`cargo test -Ztimings` would crash if you have any doc tests. This is because the `Doctest` mode unit doesn't generate any artifacts, so a map lookup was failing.
This also adds a basic test just to ensure it works.
Eric Huss [Fri, 20 Sep 2019 23:06:56 +0000 (16:06 -0700)]
Fix some rendering issues with -Ztimings.
- Cap the max width to 4096. This is still quite large, but should help for some large graphs failing to display for using too much memory.
- Don't allow labels to overflow past the right side of the graph.
- Fix issue for very fast builds causing an error because there aren't enough CPU_USAGE entries.
- Fix bug where `split_ticks` would enter an infinite loop (caused by small scale values). Added a counter to abort in case there are any other bugs.
Auto merge of #7375 - ehuss:extract-platform, r=alexcrichton
Extract Platform to a separate crate.
This moves the `Platform`, `Cfg`, `CfgExpr` types to a new crate named "cargo-platform". The intent here is to give users of `cargo_metadata` a way of parsing and inspecting cargo's platform values.
Along the way, I rewrote the error handling to remove `failure`, and to slightly improve the output.
I'm having doubts whether or not this is a good idea. As you can see from the `examples/matches.rs` example, it is nontrivial to use this (which also misses cargo's config values and environment variables). I don't know if anyone will actually use this. If this doesn't seem to have value, I would suggest closing it.
I've also included a sample script, `publish.py`, for publishing cargo itself. I suspect it will need tweaking, but I figure it would be a start and open for feedback.
Auto merge of #7381 - alexcrichton:cpu-usage-graph, r=ehuss
Update `-Ztimings` with CPU usage information
This commit updates the graph generated by `-Ztimings` to include CPU
usage information, ideally showing how Cargo/rustc used the CPU
throughout the build, ideally seeing nice periods of parallelism and
also periods of missed parallelism.
Auto merge of #7386 - alexcrichton:less-env-leak, r=ehuss
Remove all `CARGO_*` env vars in tests
Usage of `CARGO_PROFILE_*` is generating unexpected warnings in tests in
rust-lang/rust#64316 so let's just blanket remove every env var that has
a `CARGO_*` prefix which generally means Cargo-specific env vars. Tests
practically all assume that they have blank configs right now.
Auto merge of #7389 - alexcrichton:less-winapi-02, r=Eh2406
Remove dependency on `winapi` 0.2
This commit removes Cargo's dependency on `winapi` 0.2 which takes an
excessively long time to build, slowing down Windows builds. The
`winapi` 0.2 crate was pulled in via a dependency chain that looked
like:
The fix implemented here was to remove the `http` crate dependency from
`crates-io` which is only used for rendering status codes, but it's easy
enough to inline that function locally.
Alex Crichton [Thu, 19 Sep 2019 18:48:34 +0000 (11:48 -0700)]
Remove dependency on `winapi` 0.2
This commit removes Cargo's dependency on `winapi` 0.2 which takes an
excessively long time to build, slowing down Windows builds. The
`winapi` 0.2 crate was pulled in via a dependency chain that looked
like:
The fix implemented here was to remove the `http` crate dependency from
`crates-io` which is only used for rendering status codes, but it's easy
enough to inline that function locally.
Alex Crichton [Thu, 19 Sep 2019 01:07:57 +0000 (18:07 -0700)]
Remove all `CARGO_*` env vars in tests
Usage of `CARGO_PROFILE_*` is generating unexpected warnings in tests in
rust-lang/rust#64316 so let's just blanket remove every env var that has
a `CARGO_*` prefix which generally means Cargo-specific env vars. Tests
practically all assume that they have blank configs right now.
Auto merge of #7385 - ehuss:fix-tar-features, r=alexcrichton
Fix some duplicate artifact problems.
The recent cargo update failed because of duplicate artifacts with rls.
`tar` should mirror what the main manifest contains.
Partially revert #7374 by adding `serde` back to `url`. Unfortunately the `lsp-types` crate (used by rls) needs this feature. Unless anyone has a good idea on how to handle that, I don't think it can be removed.
Unblocks cargo update, which I'd like to get done before the beta branch.
Auto merge of #6892 - Goirad:doctest-xcompile, r=alexcrichton
Added ability to crosscompile doctests
This commit adds the ability to cross-compile and run doctests.
Like before cargo checks if target == host, the difference is that if there is a runtool defined in config.toml, it passes the information forward to rustdoc so that it can run the doctests with that tool. If no tool is defined and the target != host, cargo instead displays a message that doctests will not be compiled because of the missing runtool.
See [here](https://github.com/rust-lang/rust/pull/60387) for the companion PR in the rust project that modifies rustdoc to accept the relevant options as well as allow ignoring doctests on a per target level.
Partially resolves [#6460](https://github.com/rust-lang/cargo/issues/6460)
See [here](https://github.com/rust-lang/cargo/issues/7040) for the tracking issue.
Auto merge of #7377 - rust-lang:dependabot/cargo/hex-0.4, r=alexcrichton
Update hex requirement from 0.3 to 0.4
Updates the requirements on [hex](https://github.com/KokaKiwi/rust-hex) to permit the latest version.
<details>
<summary>Commits</summary>
- See full diff in [compare view](https://github.com/KokaKiwi/rust-hex/commits)
</details>
<br />
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)
Finally, you can contact us by mentioning @dependabot.
Alex Crichton [Tue, 17 Sep 2019 22:47:34 +0000 (15:47 -0700)]
Update `-Ztimings` with CPU usage information
This commit updates the graph generated by `-Ztimings` to include CPU
usage information, ideally showing how Cargo/rustc used the CPU
throughout the build, ideally seeing nice periods of parallelism and
also periods of missed parallelism.
Updates the requirements on [hex](https://github.com/KokaKiwi/rust-hex) to permit the latest version.
- [Release notes](https://github.com/KokaKiwi/rust-hex/releases)
- [Commits](https://github.com/KokaKiwi/rust-hex/commits)
Auto merge of #7311 - ehuss:pipeline-timing, r=alexcrichton
Experiment: Create timing report.
This is just an experiment, so I'm not sure if we'll want to merge it.
This adds an HTML report which gets saved to disk when the build is finished. It is primarily geared for identifying slow dependencies, and for visualizing how pipelining affects the build.
Here's an example: https://ehuss.github.io/cargo-timing.html
You can mouse over the blocks to highlight the reverse-dependencies that are released when a unit finishes. `syn` is a really good example.
It does a few other things, like displaying a message after each unit is finished. See the docs for more information.
Auto merge of #7368 - alexcrichton:canonical-urls-omg, r=ehuss
Work with canonical URLs in `[patch]`
This commit addresses an issue with how the resolver processes `[patch]`
annotations in manifests and lock files. Previously the resolver would
use the raw `Url` coming out of a manifest, but the rest of resolution,
when comparing `SourceId`, uses a canonical form of a `Url` rather than
the actual raw `Url`. This ended up causing discrepancies like those
found in #7282.
To fix the issue all `patch` intermediate storage in the resolver uses a
newly-added `CanonicalUrl` type instead of a `Url`. This
`CanonicalUrl` is then also used throughout the codebase, and all
lookups in the resolver as switched to using `CanonicalUrl` instead of
`Url`, which...
Alex Crichton [Mon, 16 Sep 2019 19:35:03 +0000 (12:35 -0700)]
Work with canonical URLs in `[patch]`
This commit addresses an issue with how the resolver processes `[patch]`
annotations in manifests and lock files. Previously the resolver would
use the raw `Url` coming out of a manifest, but the rest of resolution,
when comparing `SourceId`, uses a canonical form of a `Url` rather than
the actual raw `Url`. This ended up causing discrepancies like those
found in #7282.
To fix the issue all `patch` intermediate storage in the resolver uses a
newly-added `CanonicalUrl` type instead of a `Url`. This
`CanonicalUrl` is then also used throughout the codebase, and all
lookups in the resolver as switched to using `CanonicalUrl` instead of
`Url`, which...
Auto merge of #7373 - alexcrichton:clear-memos, r=ehuss
Clear out memoized hashes before building crates
Build script updates during execution can change the memoized hash of a
`Fingerprint`, and while previously we cleared out a single build
script's memoized hash we forgot to clear out everything that depended
on it as well. This commit pessimistically clears out all `Fingerprint`
memoized hashes just before building to ensure that during the build
everything has the most up-to-date view of the world, and when build
scripts change fingerprints everything that depends on them won't have
run yet.
Alex Crichton [Tue, 17 Sep 2019 14:04:28 +0000 (07:04 -0700)]
Clear out memoized hashes before building crates
Build script updates during execution can change the memoized hash of a
`Fingerprint`, and while previously we cleared out a single build
script's memoized hash we forgot to clear out everything that depended
on it as well. This commit pessimistically clears out all `Fingerprint`
memoized hashes just before building to ensure that during the build
everything has the most up-to-date view of the world, and when build
scripts change fingerprints everything that depends on them won't have
run yet.
Auto merge of #7350 - alexcrichton:mock-std, r=ehuss
Improve test suite for `-Zbuild-std`
This commit is aimed directly at rust-lang/wg-cargo-std-aware#33 and in
general making the `-Zbuild-std` tests more robust. The main change here
is that a new source tree is checked in, `tests/testsuite/mock-std`,
which mirrors rust-lang/rust's own tree for libstd. This mock tree is as
empty as it can be, ideally duplicating almost nothing but for not
requiring duplication of Cargo metadata about patches and such.
The end result here looks like:
* All `-Zbuild-std` tests are now run in parallel
* All tests run much more quickly since they're compiling tiny crates
instead of actually compiling libstd/libcore
* No tests require network access
* We verify that crates have access to the "custom" libraries
that we build
Coverage of tests is not currently expanded, but it's hoped that we
could add that shortly afterwards. Coverage has actually gone down
slightly since the custom target test was commented out temporarily and
the full integration test of running `-Zbuild-std` isn't run on CI any
more.
projects / cargo.git / log