Make "cargo uninstall" uninstall the cwd bins
Fixes#5916
Tested with a local build of cargo, using coreutils:
17:33:57 $ dcargo uninstall
Removing /Users/dnw/.cargo/bin/uutils
fix cargo not doing anything when the input and output mtimes are equal
That's a problem as the input may have changed in that same second but after the output got generated!
Fixes https://github.com/rust-lang/cargo/issues/5918
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.
Closes#5903
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.
Closes#5903
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.
@alexcrichton r?
@joshtriplett cc
.. with mutliple calls of:
fastmod --accept-all '\.cargo\("([^"]+)"\)\.arg\("([^"]+)"\)' '.cargo("${1} ${2}")' tests/testsuite/
until no changes are left.
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.
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.
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.
Closes#5819.
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).
cc: @Eh2406 thanks for your fix and help!
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.
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.
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.
Closes#5860
Previously build scripts were accidentally and unconditionally compiled with the
2015 edition, but they should instead use the edition of the `[package]` itself.
Closes#5860
