bors [Tue, 21 Aug 2018 19:55:15 +0000 (19:55 +0000)]
Auto merge of #5914 - alexcrichton:system-git, r=dwijnand
Add a configuration option to fetch with git-the-CLI
Currently Cargo always uses `libgit2` to perform all fetches of git
repositories, but sometimes this is not sufficient. The `libgit2` library
doesn't support all authentication schemes that `git` does and it isn't always
quite at feature parity with `git` itself, especially in terms of network
configuration.
This commit adds a configuration option to Cargo for fetching git repositories
with the `git` CLI tool rather than the internal `libgit2`. While this exposes
us to changes over time in the `git` CLI it's hopefully a very targeted use case
that doesn't change much. The internal `libgit2` library should be sufficient
for all other forms of git repository management. (and using `git` for only
fetches shouldn't slow us down much)
The new configuration option in `.cargo/config` is:
[net]
git-fetch-with-cli = true
which can also be specified with `CARGO_NET_GIT_FETCH_WITH_CLI=true` via an
environment variable.
Alex Crichton [Mon, 20 Aug 2018 17:01:16 +0000 (10:01 -0700)]
Add a configuration option to fetch with git-the-CLI
Currently Cargo always uses `libgit2` to perform all fetches of git
repositories, but sometimes this is not sufficient. The `libgit2` library
doesn't support all authentication schemes that `git` does and it isn't always
quite at feature parity with `git` itself, especially in terms of network
configuration.
This commit adds a configuration option to Cargo for fetching git repositories
with the `git` CLI tool rather than the internal `libgit2`. While this exposes
us to changes over time in the `git` CLI it's hopefully a very targeted use case
that doesn't change much. The internal `libgit2` library should be sufficient
for all other forms of git repository management. (and using `git` for only
fetches shouldn't slow us down much)
The new configuration option in `.cargo/config` is:
[net]
git-fetch-with-cli = true
which can also be specified with `CARGO_NET_GIT_FETCH_WITH_CLI=true` via an
environment variable.
bors [Mon, 20 Aug 2018 21:18:45 +0000 (21:18 +0000)]
Auto merge of #5886 - dekellum:record-package-git-head-3, r=alexcrichton
Generate .cargo_vcs_info.json and include in `cargo package` (take 2)
Implements #5629 and supersedes #5786, with the following improvements:
* With an upstream git2-rs fix (tracked #5823, validated and min version update in: #5858), no longer requires windows/unix split tests.
* Per review in #5786, drops file system output and locks for .cargo_vcs_info.json.
* Now uses serde `json!` macro for json production with appropriate escaping.
* Now includes a test of the output json format.
Possible followup:
* Per discussion in #5786, we could improve reliability of both the VCS dirty check and the git head sha1 recording by preferring (and/or warning otherwise) the local repository bytes of each source file, at the same head commit. This makes the process more appropriately like an atomic snapshot, with no sentry file or other locking required. However given my lack of a window's license and dev setup, as exhibited by troubles of #5823, this feel intuitively like too much to attempt to change in one iteration here. I accept the "best effort" concept of this feature as suggested in #5786, and think it acceptable progress if merged in this form.
bors [Mon, 20 Aug 2018 17:34:45 +0000 (17:34 +0000)]
Auto merge of #5912 - rust-lang:dependabot/cargo/opener-0.3.0, r=alexcrichton
Update opener requirement from 0.2.0 to 0.3.0
Updates the requirements on [opener](https://github.com/Seeker14491/opener) to permit the latest version.
<details>
<summary>Changelog</summary>
*Sourced from [opener's changelog](https://github.com/Seeker14491/opener/blob/master/CHANGELOG.md).*
> ## [0.3.0] - 2018-08-18
> ### Added
> - `stderr` field to `OpenError::ExitStatus` variant, which captures anything the failed process wrote to stderr.
>
> ## [0.2.0] - 2018-08-08
> ### Removed
> - The `open_sys` function, which was erroneously pub on non-Windows builds.
>
> ## [0.1.0] - 2018-08-08
> - Initial release.
</details>
<details>
<summary>Commits</summary>
- See full diff in [compare view](https://github.com/Seeker14491/opener/commits/v0.3.0)
</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 merge` will merge this PR after your CI passes on it
- `@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, 20 Aug 2018 05:27:11 +0000 (05:27 +0000)]
Update opener requirement from 0.2.0 to 0.3.0
Updates the requirements on [opener](https://github.com/Seeker14491/opener) to permit the latest version.
- [Release notes](https://github.com/Seeker14491/opener/releases)
- [Changelog](https://github.com/Seeker14491/opener/blob/master/CHANGELOG.md)
- [Commits](https://github.com/Seeker14491/opener/commits/v0.3.0)
bors [Wed, 15 Aug 2018 17:00:22 +0000 (17:00 +0000)]
Auto merge of #5856 - Eh2406:min-test, r=alexcrichton
run some tests with minimal-versions on CI
In #5757 we discovered that sum test don't pass with minimal-versions, and so only added CI for `cargo check`. This PR is to see if that is still needed, and if it is then which test rely on upstream bugfix.
bors [Wed, 15 Aug 2018 16:09:58 +0000 (16:09 +0000)]
Auto merge of #5888 - Seeker14491:opener, r=alexcrichton
Handle opening browser with `opener` crate
Fixes #5701
A note about behavior on Linux:
When looking for a browser to open the docs with, Cargo currently tries the `$BROWSER` environment variable, `xdg-open`, `gnome-open`, and finally `kde-open`, in that order. With this commit, this behavior changes; the `opener` crate always uses the `xdg-open` script, which is included in the `opener` crate. The `xdg-open` script takes care of finding a suitable browser.
bors [Fri, 10 Aug 2018 03:14:33 +0000 (03:14 +0000)]
Auto merge of #5878 - ehuss:rustdoc-json, r=alexcrichton
Support JSON with rustdoc.
This allows `cargo doc --message-format=json` to actually work.
Note that this explicitly does not attempt to support it for doctests for
several reasons:
- `rustdoc --test --error-format=json` does not work for some reason.
- Since the lib is usually compiled before running rustdoc, warnings/errors
will be emitted correctly by rustc.
- I'm unaware of any errors/warnings `rustdoc --test` is capable of producing
assuming the code passed `rustc`.
- The compilation of the tests themselves do not support JSON.
- libtest does not output json, so it's utility is limited.
bors [Fri, 10 Aug 2018 00:57:49 +0000 (00:57 +0000)]
Auto merge of #5880 - dwijnand:fix-rustfmt-instructions, r=alexcrichton
Fix rustfmt instructions in CONTRIBUTING.md
rustfmt's --skip-children is now behind --unstable-features
(rust-lang-nursery/rustfmt#2796) which only works on nightly rustfmt, so
change the install instructions too.
Dale Wijnand [Thu, 9 Aug 2018 20:21:13 +0000 (21:21 +0100)]
Fix rustfmt instructions in CONTRIBUTING.md
rustfmt's --skip-children is now behind --unstable-features
(rust-lang-nursery/rustfmt#2796) which only works on nightly rustfmt, so
change the install instructions too.
Eric Huss [Thu, 9 Aug 2018 06:52:05 +0000 (23:52 -0700)]
Support JSON with rustdoc.
This allows `cargo doc --message-format=json` to actually work.
Note that this explicitly does not attempt to support it for doctests for
several reasons:
- `rustdoc --test --error-format=json` does not work for some reason.
- Since the lib is usually compiled before running rustdoc, warnings/errors
will be emitted correctly by rustc.
- I'm unaware of any errors/warnings `rustdoc --test` is capable of producing
assuming the code passed `rustc`.
- The compilation of the tests themselves do not support JSON.
- libtest does not output json, so it's utility is limited.
bors [Tue, 7 Aug 2018 22:57:38 +0000 (22:57 +0000)]
Auto merge of #5873 - ehuss:ws-filters, r=alexcrichton
Change target filters in workspaces.
This changes it so that filters like `--bin`, `--test`, `--example`,
`--bench`, `--lib` will work in a workspace. Today, these filters
require that they match *every* package in a workspace which makes
them not very useful. This change makes it so that they only must
match at least one package.
bors [Tue, 7 Aug 2018 22:19:54 +0000 (22:19 +0000)]
Auto merge of #5858 - dekellum:git-check-logging-and-test, r=alexcrichton
Improve verbose console and log for finding git repo in package check
Third attempt to resolve #5823 by improving logging and tests. This exposes the issue to testing, via verbose console output and is dependent on alexcrichton/git2-rs#341 as just released in git2 0.7.5 crate. Thus tests *should* now pass on all platforms, incl. windows, but I also intend to bump the minimal git2 release dependency (in a subsequently added commit).
bors [Tue, 7 Aug 2018 20:48:07 +0000 (20:48 +0000)]
Auto merge of #5871 - matklad:meta-rename, r=alexcrichton
Meta rename
Some work towards https://github.com/rust-lang/cargo/issues/5583
Previously, `cargo metadata` exposed dependencies info as a graph of
package id without any additional information on edges.
However, we do want to add some data to edges, including for example,
package renames and `cfg` info.
Internally, the edges info is represented as a `Vec<Dependnecy>`. We
could have exposed that directly, but that risks exposing and
ossifying an implementation details.
So instead we collapse a `Vec<Dependnecy>` to a single JSON object,
which at the moment contains `id` and `rename` info only. It should be
possible to add additional fields to that object backwards compatibly.
Such representation does not correspond directly to any internal Cargo
data structure, but hopefully it shouldn't be to hard to maintain.
This representation also does not quite correspond to the "real
world", where dependencies are between crate (cargo targets), and not
packages. However, because each dep edge is a JSON object, adding a
target filter should be possible, which would handle dev-, build-, and
potential future bin-specific dependencies backwards-compatibly.
Eric Huss [Tue, 7 Aug 2018 20:05:22 +0000 (13:05 -0700)]
Change target filters in workspaces.
This changes it so that filters like `--bin`, `--test`, `--example`,
`--bench`, `--lib` will work in a workspace. Today, these filters
require that they match *every* package in a workspace which makes
them not very useful. This change makes it so that they only must
match at least one package.
Aleksey Kladov [Tue, 7 Aug 2018 09:37:29 +0000 (12:37 +0300)]
Add rename info to Cargo metadata
Previously, `cargo metadata` exposed dependencies info as a graph of
package id without any additional information on edges.
However, we do want to add some data to edges, including for example,
package renames and `cfg` info.
Internally, the edges info is represented as a `Vec<Dependnecy>`. We
could have exposed that directly, but that risks exposing and
ossifying an implementation details.
So instead we collapse a `Vec<Dependnecy>` to a single JSON object,
which at the moment contains `id` and `rename` info only. It should be
possible to add additional fields to that object backwards compatibly.
Such representation does not correspond directly to any internal Cargo
data structure, but hopefully it shouldn't be to hard to maintain.
This representation also does not quite correspond to the "real
world", where dependencies are between crate (cargo targets), and not
packages. However, because each dep edge is a JSON object, adding a
target filter should be possible, which would handle dev-, build-, and
potential future bin-specific dependencies backwards-compatibly.
bors [Mon, 6 Aug 2018 17:31:07 +0000 (17:31 +0000)]
Auto merge of #5870 - bmwill:fix-fetch-target-tests, r=alexcrichton
fetch: skip target tests when cross_compile is disabled
It was reported in #5864 that the fetch-by-target tests fail when run on a non-x86 platform. This is due to the cross_compile module being disabled when running on non-x86 platforms. Fix this by skipping the two fetch tests which rely on the cross_compile module, when cross_compile has been disabled.
Signed-off-by: Brandon Williams <bmwill@google.com>
bors [Mon, 6 Aug 2018 15:12:01 +0000 (15:12 +0000)]
Auto merge of #5862 - kennytm:capture-rustc-output, r=alexcrichton
Fully capture rustc and rustdoc output when -Zcompile-progress is passed
Fixes #5764 and #5695.
On Windows, we will parse the ANSI escape code into console commands via my `fwdansi` package, based on @ishitatsuyuki's idea in https://github.com/rust-lang/cargo/issues/5695#issuecomment-406300234. Outside of Windows the content is forwarded as-is.
bors [Sat, 4 Aug 2018 18:15:43 +0000 (18:15 +0000)]
Auto merge of #5861 - alexcrichton:build-script-edition, r=ehuss
Fix the edition build scripts are compiled with
Previously build scripts were accidentally and unconditionally compiled with the
2015 edition, but they should instead use the edition of the `[package]` itself.
Alex Crichton [Sat, 4 Aug 2018 15:44:16 +0000 (08:44 -0700)]
Fix the edition build scripts are compiled with
Previously build scripts were accidentally and unconditionally compiled with the
2015 edition, but they should instead use the edition of the `[package]` itself.