bors [Tue, 1 Oct 2019 20:35:54 +0000 (20:35 +0000)]
Auto merge of #7462 - hbina:redundant_borrow, r=ehuss
Removed redundant borrow
As described here https://rust-lang.github.io/rust-clippy/master/#needless_borrow.
rust-clippy is complaining that the related borrows are unnecessary.
bors [Tue, 1 Oct 2019 19:01:47 +0000 (19:01 +0000)]
Auto merge of #7361 - Eh2406:public_dependency-as-type_4, r=alexcrichton
Public dependency refactor and re-allow backjumping
There were **three** attempts at vanquishing exponential time spent in Public dependency resolution. All failures. All three started with some refactoring that seams worth saving. Specifically the data structure `public_dependency` that is used to test for Public dependency conflicts is large, tricky, and modified in line. So lets make it a type with a name and move the interactions into methods.
Next each attempt needed to know how far back to jump to undo any given dependency edge. I am fairly confident that any full solution will need this functionality. I also think any solution will need a way to represent richer conflicts than the existing "is this pid active". So let's keep the `still_applies` structure from the last attempt.
Last each attempt needs to pick a way to represent a Public dependency conflict. The last attempt used three facts about a situation.
- `a1`: `PublicDependency(p)` witch can be read as the package `p` can see the package `a1`
- `b`: `PublicDependency(p)` witch can be read as the package `p` can see the package `b`
- `a2`: `PubliclyExports(b)` witch can be read as the package `b` has the package `a2` in its publick interface.
This representation is good enough to allow for `backjumping`. I.E. `find_candidate` can go back several frames until the `age` when the Public dependency conflict was introduced. This optimization, added for normal dependencies in #4834, saves the most time in practice. So having it for Public dependency conflicts is important for allowing real world experimentation of the Public dependencies feature. We will have to alter/improve/replace this representation to unlock all of the important optimizations. But I don't know one that will work for all of them and this is a major step forward.
As described here https://rust-lang.github.io/rust-clippy/master/#needless_borrow.
rust-clippy is complaining that the related borrows are unnecessary.
Auto merge of #7417 - alexcrichton:less-hashing, r=Eh2406
Go back to not hashing `RUSTFLAGS` in `-Cmetadata`
This is a moral revert of #6503 but not a literal code revert. This
switches Cargo's behavior to avoid hashing compiler flags into
`-Cmetadata` since we've now had multiple requests of excluding flags
from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO
options. These options should only affect how the compiler is
invoked/compiled and not radical changes such as symbol names, but
symbol names are changed based on `-Cmetadata`. Instead Cargo will still
track these flags internally, but only for reinvoking rustc, and not for
caching separately based on rustc flags.
Dan Aloni [Fri, 27 Sep 2019 19:28:44 +0000 (22:28 +0300)]
named-profiles: add backward compatibility if feature is disabled
The effects over the profile used by targets are made conditional
in this commit, using the old scheme if the `named-profiles` feature
is disabled. This also affects the `profile_targets` tests, which
now have two modes - stable, and nightly with the feature enabled.
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.
Alex Crichton [Mon, 23 Sep 2019 19:14:52 +0000 (12:14 -0700)]
Go back to not hashing `RUSTFLAGS` in `-Cmetadata`
This is a moral revert of #6503 but not a literal code revert. This
switches Cargo's behavior to avoid hashing compiler flags into
`-Cmetadata` since we've now had multiple requests of excluding flags
from the `-Cmetadata` hash: usage of `--remap-path-prefix` and PGO
options. These options should only affect how the compiler is
invoked/compiled and not radical changes such as symbol names, but
symbol names are changed based on `-Cmetadata`. Instead Cargo will still
track these flags internally, but only for reinvoking rustc, and not for
caching separately based on rustc flags.
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.