bors [Fri, 29 Mar 2019 12:31:50 +0000 (12:31 +0000)]
Auto merge of #6792 - collin5:patch-1, r=alexcrichton
Fix Init for Fossil SCM project
I believe [here](https://github.com/rust-lang/cargo/pull/6792/files#diff-149dd4362a3b0dc13b113762713119dfL527) we should be checking if `.fossil` doesn't exist instead of the latter!
bors [Tue, 26 Mar 2019 23:22:07 +0000 (23:22 +0000)]
Auto merge of #6534 - ehuss:meta-deps-name-null, r=alexcrichton
cargo metadata: Don't show `null` deps.
If a package has a dependency without a library target, the "name" field was
showing up as null in `resolve.nodes.deps`. At this time (AFAIK), binary-only
dependencies are always ignored. Instead of making users filter out this entry
(or more commonly, crash), just don't include it.
bors [Tue, 26 Mar 2019 22:25:44 +0000 (22:25 +0000)]
Auto merge of #6785 - ehuss:fingerprint-cleanup, r=dwijnand
Some fingerprint cleanup.
Just a minor cleanup.
Move `CARGO_PKG_*` values from Metadata to Fingerprint (added in #3857). Closes #6208. This prevents stale artifacts from being left behind when these values change. Also tracks changes to the "repository" value (added in #6096).
Remove `edition` as a separate field. It is already tracked in `target`. This was required previously to #5816 which added per-target editions.
Also adds a helper to the testsuite to make globbing easier.
bors [Mon, 25 Mar 2019 19:04:21 +0000 (19:04 +0000)]
Auto merge of #6778 - phil-opp:canonicalize-config-target, r=alexcrichton
Canonicalize default target if it ends with `.json`
Targets that end with `.json` are not target triples but paths to target configuration files. We currently canonicalize all `.json` paths that are passed as `--target` so that the paths are still valid when building dependencies (where the current working directory is changed).
This commit adds the same canonicalization to default targets specified in a `build.target` key in a `.cargo/config` file by adding a new `Config::target_triple` function.
bors [Sun, 24 Mar 2019 21:51:44 +0000 (21:51 +0000)]
Auto merge of #6781 - ehuss:fix-panic-unwind-extra, r=Eh2406
Fix setting `panic=unwind` compiling lib a extra time.
Explicitly setting `panic=unwind` in a profile could cause the `lib` target to be built multiple times when it shouldn't be. This is because libs as a test dependency explicitly clear the panic setting (because they are incompatible with `abort`). However, the deduplication logic doesn't know that `panic=None` is the same as `panic=Some("unwind")`. This changes it so there is an explicit enum that defaults to `PanicStrategy::Unwind`.
bors [Thu, 21 Mar 2019 19:00:57 +0000 (19:00 +0000)]
Auto merge of #6771 - sgrif:sg-always-show-errors-nicely, r=alexcrichton
Always nicely show errors from crates.io if possible
Currently if Cargo ever gets a non-200 response, it will either not show
the error at all (if it was a 403 or 404), or spit out the entire
response body. Historically crates.io has served a 200 for most errors
to work around this, but we've stopped doing this as it causes problems
for other clients.
Additionally, we're starting to server more errors that have semantic
meaning (429 for rate limiting, 503 when we're in read only mode). If
the request specifies "Accept: application/json", we should ideally
return the errors formatted nicely. This isn't always true, but it's
what we'd like to do going forward.
While the output that Cargo puts out at least contains the actual
message, it's buried under a ton of useless info. This changes the
behavior so that if the response was valid JSON in the format that Cargo
expects, it just shows that (along with a description of the response
status), and only falls back to spitting out everything if it can't
parse the response body.
I'd love to add some more tests for this, but I've had trouble finding
anywhere in the test suite that exercises these paths.
Sean Griffin [Thu, 21 Mar 2019 18:10:43 +0000 (12:10 -0600)]
Always nicely show errors from crates.io if possible
Currently if Cargo ever gets a non-200 response, it will either not show
the error at all (if it was a 403 or 404), or spit out the entire
response body. Historically crates.io has served a 200 for most errors
to work around this, but we've stopped doing this as it causes problems
for other clients.
Additionally, we're starting to server more errors that have semantic
meaning (429 for rate limiting, 503 when we're in read only mode). If
the request specifies "Accept: application/json", we should ideally
return the errors formatted nicely. This isn't always true, but it's
what we'd like to do going forward.
While the output that Cargo puts out at least contains the actual
message, it's buried under a ton of useless info. This changes the
behavior so that if the response was valid JSON in the format that Cargo
expects, it just shows that (along with a description of the response
status), and only falls back to spitting out everything if it can't
parse the response body.
I'd love to add some more tests for this, but I've had trouble finding
anywhere in the test suite that exercises these paths.
bors [Wed, 20 Mar 2019 19:36:28 +0000 (19:36 +0000)]
Auto merge of #6767 - ehuss:fix-git-ignore-of-root, r=Eh2406
Allow `cargo fix` if gitignore matches root working dir.
If `.gitignore` had a rule that matched the root working directory, it would believe that the whole thing is ignored. This is not usually how git works (AFAIK), so don't check gitignore against the root.
bors [Tue, 19 Mar 2019 15:47:25 +0000 (15:47 +0000)]
Auto merge of #6761 - alexcrichton:handle-toml, r=ehuss
Handle backcompat hazard with `toml` crate
The 0.5.0 release contained a
[bugfix](https://github.com/alexcrichton/toml-rs/pull/280) which
previously successfully parsed invalid TOML files, so we'll need to
manually handle that in Cago to ensure that we don't accidentally
regress crates, but rather instead give them an appropriate amount of
time to get fixed.
Alex Crichton [Mon, 18 Mar 2019 14:32:59 +0000 (07:32 -0700)]
Handle backcompat hazard with `toml` crate
The 0.5.0 release contained a
[bugfix](https://github.com/alexcrichton/toml-rs/pull/280) which
previously successfully parsed invalid TOML files, so we'll need to
manually handle that in Cago to ensure that we don't accidentally
regress crates, but rather instead give them an appropriate amount of
time to get fixed.
bors [Mon, 18 Mar 2019 06:44:55 +0000 (06:44 +0000)]
Auto merge of #6760 - rust-lang:dependabot/cargo/toml-0.5.0, r=dwijnand
Update toml requirement from 0.4.2 to 0.5.0
Updates the requirements on [toml](https://github.com/alexcrichton/toml-rs) to permit the latest version.
<details>
<summary>Release notes</summary>
*Sourced from [toml's releases](https://github.com/alexcrichton/toml-rs/releases).*
> ## Preserve order feature, minor fixes
> - Add `preserve_order` Cargo feature. This retains the order of map keys in `toml::Value`. ([#278](https://github-redirect.dependabot.com/alexcrichton/toml-rs/issues/278))
> - Fix issue [#279](https://github-redirect.dependabot.com/alexcrichton/toml-rs/issues/279) where some duplicate table headers were accepted. Added `Deserializer::set_allow_duplicate_after_longer_table` for anyone who wants to retain the old, broken behavior. ([#280](https://github-redirect.dependabot.com/alexcrichton/toml-rs/issues/280))
> - Fix case sensitivity with T, Z, and E. ([#290](https://github-redirect.dependabot.com/alexcrichton/toml-rs/issues/290))
> - Add `PartialEq` to `de::Error`. ([#292](https://github-redirect.dependabot.com/alexcrichton/toml-rs/issues/292))
</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 ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major 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)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- 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.
dependabot[bot] [Mon, 18 Mar 2019 05:35:49 +0000 (05:35 +0000)]
Update toml requirement from 0.4.2 to 0.5.0
Updates the requirements on [toml](https://github.com/alexcrichton/toml-rs) to permit the latest version.
- [Release notes](https://github.com/alexcrichton/toml-rs/releases)
- [Commits](https://github.com/alexcrichton/toml-rs/compare/0.4.2...0.5.0)
bors [Sat, 16 Mar 2019 17:53:28 +0000 (17:53 +0000)]
Auto merge of #6752 - ea2973929:cargo-book-2.4-dependencies-use-2018, r=ehuss
Don't need extern crate in 2018
The example in 2.4 Dependencies uses `extern crate` which you don't need in edition 2018. As a beginner Rustacean I find it's confusing that so many examples are still using `extern crate` so here is a pull request to fix that.
Alex Crichton [Thu, 14 Mar 2019 15:17:38 +0000 (08:17 -0700)]
Release a jobserver token while locking a file
This is intended to fix #6747 where multiple Cargos invoked with the
same jobserver would all have their own token but not actually run
concurrently due to file locking. Instead the fix is that whenever Cargo
blocks for a file lock with a configured global jobserver, a token is
released just before we block and then reacquired afterwards. This way
we should ensure that we're not hogging a cpu/token unnecessarily
without doing any work!
bors [Fri, 15 Mar 2019 03:59:07 +0000 (03:59 +0000)]
Auto merge of #6749 - calebcartwright:docs-publish-command, r=ehuss
Minor doc fix for publish command synopsis
I think the synopsis for the [publish command doc]( https://doc.rust-lang.org/stable/cargo/commands/cargo-publish.html) should be `cargo publish` but it currently has `package` (screenshot below).
Took a shot at making the change, not positive I did it the correct way though 😄
bors [Wed, 13 Mar 2019 15:49:19 +0000 (15:49 +0000)]
Auto merge of #6740 - ehuss:package-change-detection, r=alexcrichton
Stricter package change detection.
This changes it so that when `cargo package` verifies that nothing has modified any source files that it hashes the files' contents instead of checking for mtime changes. mtimes are not always reliable.
This also changes it so that it checks *all* files in the package file. Previously it skipped files based on search rules such as the `exclude` list.
bors [Mon, 11 Mar 2019 18:51:14 +0000 (18:51 +0000)]
Auto merge of #6734 - ehuss:fingerprint-build-path-only, r=alexcrichton
Fingerprint build script deps only for path packages.
#6720 introduced some protection that if there is a build script, and two commands are used (such as `cargo build` then `cargo test`), the second command would correctly get rebuilt. However, the way it was implemented relies on mtimes working correctly. A common use case is to cache built dependencies in Docker, and Docker zeros the nanoseconds from mtime when the image is saved. This caused all packages that had build scripts to get rebuilt when the Docker image runs.
The solution here is to only use the #6720 protection for local (path) packages. This runs under the assumption that mtimes need to work for those anyways.
The consequence is that the scenario in #6720 will no longer work for detecting changes in registry dependencies with build scripts. Fixing that final edge case is nontrivial. Since it is unlikely to happen often, I figure this workaround should be sufficient for now.
cc https://github.com/integer32llc/rust-playground/issues/469
cc https://github.com/rust-lang/rust/issues/59061
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 ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major 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)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- 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.
dependabot[bot] [Thu, 7 Mar 2019 05:50:26 +0000 (05:50 +0000)]
Update glob requirement from 0.2.11 to 0.3.0
Updates the requirements on [glob](https://github.com/rust-lang/glob) to permit the latest version.
- [Release notes](https://github.com/rust-lang/glob/releases)
- [Commits](https://github.com/rust-lang/glob/compare/0.2.11...0.3.0)
bors [Wed, 6 Mar 2019 19:24:30 +0000 (19:24 +0000)]
Auto merge of #6721 - ehuss:doc-test-relax, r=dwijnand
Relax some rustdoc tests.
Unblocks rust-lang/rust#56732 which makes a minor change to the output for rustdoc. These tests are being a little overly specific, reduce them to checking just the important part.
bors [Wed, 6 Mar 2019 17:01:23 +0000 (17:01 +0000)]
Auto merge of #6720 - ehuss:build-script-fingerprint, r=alexcrichton
Include build script execution in the fingerprint.
This adds information about the execution of a build script to the fingerprint. Previously, no information was included, and cargo relied on dirty propagation in `JobQueue` to trigger recompiles. However, if two separate targets are built via separate commands (such as `cargo build` then `cargo test`), the second command did not know that the build script was updated, and thus was incorrectly treated as "fresh".
This works by including the timestamp of the last time the build script was ran in the fingerprint. For overridden build scripts, it includes the replaced output.
bors [Wed, 6 Mar 2019 03:24:32 +0000 (03:24 +0000)]
Auto merge of #6653 - Eh2406:min-pub-dep, r=alexcrichton
part of the infrastructure for public & private dependencies in the resolver
This is part of my work on public & private dependencies in the resolver from #6129. As discussed there the proptest fuzzers are happy to find exponential blow up with all the back jumping strategies I have tried. So this PR does not have a back jumping strategie nor does it have the proptest fuzzers generating public dependencies. These will both need to change for the feature to stabilize. In the meantime it gives the correct results on the cases it can handle.
With https://github.com/rust-lang/rust/pull/57586 landed there is a lot of work to do on Cargos front end. Adding a UI for this, passing the relevant things to rustc, passing it to crates.io, passing it to cargo-metadata. This is good enough to allow that work to proceed.
bors [Wed, 27 Feb 2019 22:21:16 +0000 (22:21 +0000)]
Auto merge of #6614 - claudijd:https_all_the_things, r=ehuss
HTTPS all the things
Noticed that we still have a bunch of HTTP links, which could present mild MiTM risks that we can totally remove.
One short coming of this was:
cargo/src/etc/_cargo:13 "http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Completion-Functions" of which does not have an HTTPS equivalent yet.
projects / cargo.git / log