bors [Wed, 19 Aug 2020 20:22:52 +0000 (20:22 +0000)]
Auto merge of #8609 - ehuss:resolver-semver, r=Eh2406
Add chapters on dependency resolution and SemVer compatibility.
This adds two documentation chapters, one on the resolver and one on SemVer compatibility. These are intended to help guide users on how to version their package and how to use dependencies.
I did not document `[patch]` resolution. Perhaps someday in the future the the "Overriding dependencies" chapter can be expanded to include more details on how patch works, and how to properly use it. I have a bunch of notes on this, but I want to defer it till later.
The SemVer compatibility guidelines were guided by [RFC 1105](https://github.com/rust-lang/rfcs/blob/master/text/1105-api-evolution.md), but are edited and expanded based on my own personal observations. I tried to highlight when some rules do not appear to have consensus on behavior. I would be happy for any additions or modifications to the rule list. I have a list of additional things to add, but I wanted to get the ball rolling, and it might take a while finish them.
Each compatibility entry has an example, and there is a small script which tests all the examples to ensure they work like they are supposed to. This script checks against the compiler output, which can be fragile over time. If that becomes too troublesome, we can probably find some more relaxed checks. I think checking the error is important because I've run into cases in the past where using basic "compile_fail" annotations were misleading because the examples were failing for the wrong reason.
bors [Wed, 19 Aug 2020 19:30:21 +0000 (19:30 +0000)]
Auto merge of #8611 - hbina:rename_into_url, r=ehuss
Renames SourceId::into_url -> SourceId::as_url
While studying the source code, I am surprised to see that `into_url`
does not actually consume its caller when a function with such name
usually does. Additionally, there is a trait in `cargo::util::IntoUrl`
with the same and does exactly what you expect, consumes itself and yields
a `CargoResult<Url>`.
bors [Tue, 18 Aug 2020 16:52:45 +0000 (16:52 +0000)]
Auto merge of #8629 - EmbarkStudios:master, r=ehuss
Fix bug with PathAndArg config values
This fixes an issue I noticed when trying to specify a target runner via the [`CARGO_TARGET_{triplet}_RUNNER`](https://doc.rust-lang.org/cargo/reference/config.html#targettriplerunner) environment variable, expecting it to override the value in our `.cargo/config.toml` file, which was giving quite strange errors until I figured out that cargo was actually merging the config file's values with the environment's values.
This change adds a small hack to use and `UnmergedStringList` from `PathAndArgs` instead of just plain `StringList`, which uses the type in the deserializer to determine if `Config::get_list_or_string` should merge the values from the config file(s) with the environment as it was doing before, or else only use the environment to the exclusion of the config file(s) if the key was set in the environment.
I also added a test for this to confirm both the bug and the fix.
bors [Tue, 18 Aug 2020 15:08:14 +0000 (15:08 +0000)]
Auto merge of #8627 - ehuss:run-proc-err, r=Eh2406
Show full error context on `cargo run` error.
If there was an error exec-ing a process with `cargo run`, the error message was not displayed. The code was calling `downcast` to a `ProcessError` which erased the surrounding error context. As shown in the modified test, it should now include a `Caused by:` message with the underlying error message.
While studying the source code, I am surprised to see that `into_url`
does not actually consume the string when a function with such name
usually does. Additionally, there are traits in `cargo::util::IntoUrl`
with the same and does exactly what you expect, consumes T and yields
a `Url`.
Alex Crichton [Fri, 7 Aug 2020 21:46:15 +0000 (14:46 -0700)]
Build manpage archive deterministically
Keep deterministic builds for Cargo! The changes here are:
* Sort files being added to the archive to ensure they're added in the
same order on all platforms.
* Flag the archive builder as "deterministic mode" which means it won't
pick up fields like mtime.
bors [Thu, 6 Aug 2020 17:48:55 +0000 (17:48 +0000)]
Auto merge of #8571 - canova:publish-default, r=ehuss
Default cargo publish to the alt registry if it's the only allowed one
Hi, this PR fixes #8036. Previously if we had only one allowed registry in Cargo.toml file, `cargo publish` was failing. But with this PR, we are defaulting to the only allowed registry with printing a note if there is only one registry in that array. I believe this will make things easier for people who use an alternative registry all the time.
bors [Tue, 4 Aug 2020 23:14:37 +0000 (23:14 +0000)]
Auto merge of #8587 - ehuss:close_output-fix, r=alexcrichton
Fix close_output test.
The close_output test was randomly failing on rust-lang/rust's CI. This should fix the error. I ran the test in a loop on the rust-lang 16-thread CPU for 10,000 times over the course of 1.5 hours without fail. The same stress test without this patch failed relatively easily.
I'm a bit on the fence, as this means the test is no longer testing a realistic scenario (the compiler usually doesn't emit a megabyte of diagnostics). Moving this test to a single-threaded runner should also solve the problem. I can't decide if it matters enough to bother. WDYT?
bors [Mon, 3 Aug 2020 21:20:46 +0000 (21:20 +0000)]
Auto merge of #8456 - ehuss:embedded-man, r=alexcrichton
Display embedded man pages for built-in commands.
This changes `cargo help COMMAND` to display the man page for the given command. `cargo COMMAND --help` continues to show the basic clap output.
The man pages are embedded in the executable in a compressed format. There's also a copy of the man pages in text format for platforms that do not have the `man` executable (like Windows).
It is unfortunate to check in more pre-generated files. I hope in the future that the usage of asciidoc can be replaced with something else (possibly a custom markdown-based solution).
Matthias Krüger [Sat, 1 Aug 2020 11:15:35 +0000 (13:15 +0200)]
use sort_by_key() instead of comparing by keys manually
replace format!() macro by String::from()
use eprintln() instead of manually writing to std::io::stderr
bors [Mon, 3 Aug 2020 18:37:44 +0000 (18:37 +0000)]
Auto merge of #8577 - ehuss:mdman, r=alexcrichton
Add mdman for generating man pages.
This introduces a new utility called `mdman` that converts a markdown-formatted document to a man page. This replaces asciidoctor, with the intent to make it easier to contribute, easier to have consistent formatting across platforms, and easier to generate plain-text documents for use on Windows (for #8456). This also includes a number of formatting fixes.
There is some documentation in the `mdman/doc` directory explaining how to use it, and the docs in `src/doc/README.md` have been updated (this explains the structure of the files). The Makefile has been replaced with a simple shell script.
CI has been updated to verify the checked-in docs are up-to-date. Perhaps in the future, these can be generated automatically (perhaps by `build.rs`?), but since that requires a bit of build system work (like upstream rust), this is deferred till later.
bors [Mon, 3 Aug 2020 15:46:14 +0000 (15:46 +0000)]
Auto merge of #8579 - matthiaskrgr:cargo_login_message, r=alexcrichton
cargo login: make login message less ambiguous
The previous message
"please visit https://crates.io/me and paste the API Token below"
Had me waiting for a token to appear in the command line which I would then paste into the website.
Rephrase to
"please paste the api token found on https://crates.io/me below"
to clarify where to paste from and where to paste to.
Matthias Krüger [Sun, 2 Aug 2020 16:04:12 +0000 (18:04 +0200)]
cargo login: make login message less ambiguous
The previous message
"please visit https://crates.io/me and paste the API Token below"
Had me waiting for a token to appear in the command line which I would then paste into the website.
Rephrase to
"please paste the api token found on https://crates.io/me below"
to clarify where to paste from and where to paste to.
Auto merge of #8561 - icorbrey:git-dep-lock-docs, r=ehuss
Emphasize git dependency version locking behavior.
Added a section in `src/doc/src/reference/specifying-dependencies.md` clarifying Cargo's version locking behavior when adding `git` dependencies:
```
Once a `git` dependency has been added, Cargo will lock that dependency to the
latest commit at the time. New commits will not be pulled down automatically
once the lock is in place. However, they can be pulled down manually with
`cargo update`.
```
Auto merge of #8554 - alexcrichton:update-lockfile-rollout, r=ehuss
Update lock file encodings on changes
This commit alters Cargo's lockfile encoding update strategy from its
previous incarnation. Previously Cargo had two versions, one for new
lock files and one for old lock files. Each of these versions were
different and would affect how Cargo manages lock file updates. The
intention was that we'd roll out defaults to new lock files first and
then later to preexisting lock files. This requires two separate
changes, though, and it's not necessarily clear when to start updating
old lock files. Additionally when old lock files were opted in it would
break builds using `--locked` if they simply updated Cargo because Cargo
would would want to bring the lock file versions forward.
The purpose of this change is to solve these issues. The new strategy
for updating a lock file's encoding is to simply preserve what's already
existing on the filesystem until we actually decide to write out a new
lock file. When Cargo updates a lock file on-disk then it will, at that
time, update the lock file encoding to whatever the current default is.
This means that there's only one version number to keep track of (the
default for encoding). Cargo will always preserve the preexisting
encoding unless another change is required to the lock file.
Auto merge of #8559 - ehuss:fix-lto-tests-flaky, r=alexcrichton
Fix sporadic lto test failures.
These tests can fail because the order of the messages is not deterministic. The two `foo` jobs start in parallel, so the order can be swapped. Results in an error like:
Auto merge of #8553 - alexcrichton:more-maybe-spurious, r=ehuss
Flag git http errors as maybe spurious
This showed up in #8544 with an error message of "stream ended at an
unexpected time; class=Http" which sounds like a spurious error.
Termination of a network connection can happen at any time! For now try
to assist in that error by adding another class of error to the list of
maybe spurious errors.
Alex Crichton [Tue, 28 Jul 2020 19:17:55 +0000 (12:17 -0700)]
Update lock file encodings on changes
This commit alters Cargo's lockfile encoding update strategy from its
previous incarnation. Previously Cargo had two versions, one for new
lock files and one for old lock files. Each of these versions were
different and would affect how Cargo manages lock file updates. The
intention was that we'd roll out defaults to new lock files first and
then later to preexisting lock files. This requires two separate
changes, though, and it's not necessarily clear when to start updating
old lock files. Additionally when old lock files were opted in it would
break builds using `--locked` if they simply updated Cargo because Cargo
would would want to bring the lock file versions forward.
The purpose of this change is to solve these issues. The new strategy
for updating a lock file's encoding is to simply preserve what's already
existing on the filesystem until we actually decide to write out a new
lock file. When Cargo updates a lock file on-disk then it will, at that
time, update the lock file encoding to whatever the current default is.
This means that there's only one version number to keep track of (the
default for encoding). Cargo will always preserve the preexisting
encoding unless another change is required to the lock file.
As stated in #8486 it would help to the discovery of the
builtin aliases the facto of printing them with the
`cargo --list` command.
- Extracted the builtin aliases currently implemented to a
separated `const`.
- Make all of the functions that interact with these aliases
point to that function.
- Refactored the `list_commands` fn in order to include with the
builtin and external commands, the builtin aliases that come with
cargo by default.
- Added a test that checks that the aliases that currently
are builtin with cargo are indeed being printed with the rest
of the commands when `cargo --list` is called.
The output on my machine looks like this:
```
$ cargo --list
Installed Commands:
b alias: build
bench Execute all benchmarks of a local package
build Compile a local package and all of its dependencies
c alias: check
check Check a local package and all of its dependencies for errors
clean Remove artifacts that cargo has generated in the past
doc Build a package's documentation
fetch Fetch dependencies of a package from the network
fix Automatically fix lint warnings reported by rustc
generate-lockfile Generate the lockfile for a package
git-checkout This subcommand has been removed
init Create a new cargo package in an existing directory
install Install a Rust binary. Default location is $HOME/.cargo/bin
locate-project Print a JSON representation of a Cargo.toml file's location
login Save an api token from the registry locally. If token is not specified, it will be read from stdin.
metadata Output the resolved dependencies of a package, the concrete used versions including overrides, in machine-readable format
new Create a new cargo package at <path>
owner Manage the owners of a crate on the registry
package Assemble the local package into a distributable tarball
pkgid Print a fully qualified package specification
publish Upload a package to the registry
r alias: run
read-manifest Print a JSON representation of a Cargo.toml manifest.
run Run a binary or example of the local package
rustc Compile a package, and pass extra options to the compiler
rustdoc Build a package's documentation, using specified custom flags.
search Search packages in crates.io
t alias: test
test Execute all unit and integration tests and build examples of a local package
tree Display a tree visualization of a dependency graph
uninstall Remove a Rust binary
update Update dependencies as recorded in the local lock file
vendor Vendor all dependencies for a project locally
verify-project Check correctness of crate manifest
version Show version information
yank Remove a pushed crate from the index
clippy
clippy
clippy
clippy
flamegraph
fmt
fmt
fmt
fmt
miri
miri
miri
miri
outdated
tree
```
As discussed with @ehuss the `BTreeSet` enforces `Ord` therefore, the aliases get mixed with the commands since they're passed through the same function.
It can be refactored to appear separately, but, the code will be more spread and now it's all in just one file (which I believe is easier to maintain and review).
As @ehuss correctly suggested, we could just declare
in one `const` structure for every builtin alias the
following: `(alias, aliased_command, description)`.
Therefore, the suggestion has been applied and the
`BUILTIN_ALIASES` const has been refactored.
Also, the `builtin_aliases_execs` now parses the
`BUILTIN_ALIASES` const searching for a
"possible alias command" returning an option with the
previous info structure or `None`.
Alex Crichton [Tue, 28 Jul 2020 18:33:10 +0000 (11:33 -0700)]
Flag git http errors as maybe spurious
This showed up in #8544 with an error message of "stream ended at an
unexpected time; class=Http" which sounds like a spurious error.
Termination of a network connection can happen at any time! For now try
to assist in that error by adding another class of error to the list of
maybe spurious errors.
Auto merge of #8552 - icorbrey:test-name-filtering-docs, r=ehuss
Clarify test name filter usage
I set aside the description of the usage example in the top description section and added a more concise example in the example section at the bottom of the man page. I also changed the wording of the usage example up top a bit to be more search-friendly since "filter" is a common keyword to search for.
Isaac Corbrey [Tue, 28 Jul 2020 14:19:58 +0000 (05:19 -0900)]
fix: Clarify test name filter usage
Set aside description of the usage example in the top description section and added a more consise example in the example section at the bottom of the man page.
Auto merge of #8551 - CPerezz:manifest_edition_nit, r=Eh2406
Revert Cargo Book changes for default edition
On #8543 it was introduced a change on the Cargo Book docs
where it was incorrectly stated that the default edition for
the Cargo Manifest was `2018` when indeed, as @ehuss correctly stated
in https://github.com/rust-lang/cargo/pull/8543#issuecomment-663769077
it is not.
Therefore, as @Eh2406 asked for, I made the PR reverting this changes
and leaving the Cargo Book docs as they were before.
On #8543 it was introduced a change on the Cargo Book docs
where it was incorrectly stated that the default edition for
the Cargo Manifest was `2018` when indeed, as @ehuss correctly stated
in https://github.com/rust-lang/cargo/pull/8543#issuecomment-663769077
it is not.
Therefore, as @Eh2406 asked for, I made the PR reverting this changes
and leaving the Cargo Book docs as they were before.
Auto merge of #8522 - alexcrichton:revert-master, r=ehuss
Prepare for not defaulting to master branch for git deps
This PR is the "equivalent" of https://github.com/rust-lang/cargo/pull/8503 for the nightly channel of Rust (the master branch of Cargo). The purpose of this change is to fix the breakage from https://github.com/rust-lang/cargo/pull/8364 but to still pave a path forward to enabling the feature added in https://github.com/rust-lang/cargo/pull/8364, namely reinterpreting dependency directives without a `branch` directive as depending on `HEAD` insead of depending on `master`.
This is a series of commits which implements a few mitigation strategies, but they're all adding up into a larger plan to roll out this change with, ideally, no breaking changes for those "reasonably" keeping up with Rust. The changes here are:
* Cargo still internally differentiates between `DefaultBranch` and `Branch("master")`, so it knows what you wrote in the manifest. These two, however, hash and equate together so everything in Cargo considers them equivalent.
* Cargo will now issue a warning whenever it fetches a repository pinned to `DefaultBranch` and the branch's `master` branch doesn't actually match `HEAD`. This avenue of breakage didn't arise but I added it here for completionism about not having to deal with breakage from this change again.
* Cargo has now implemented a new future lockfile format. Internally this is dubbed "v3". The changes in this format is that it will have a `version` marker at the top of the file as well as encoding git dependencies different. Today `DefaultBranch` and `Branch("master")` encode the same way, but in the future they will encode differently.
* Cargo now has a warning where if you have a mixture of `DefaultBranch` and `Branch("master")` in your build. The intention here is to get everyone on one or the other so the transition to the new lock file format can go smoothly.
With all of these pieces in place the intention is that there is no breakage from #8364 as well. Additionally projects that *would* break will receive warnings. (note that projects "broken" today, those we've got issues for, will likely not get warnings, but that's because it was accidental we broke them). The long-term plan is to let this bake for quite some time, and then as part of the same change land an update to the new lock file format as well as "fixing" `SourceId` to consider these two directives different. When this change happens we should have guaranteed, for all currently active projects, they're either only using `branch = "master"` or no directive at all. We can therefore unambiguosly read the previous `Cargo.lock` to transition it into a new `Cargo.lock` which will either have `?branch=master` or nothing.
I'm not sure how long this will need to bake for because unfortunately version changes to `Cargo.lock` cannot be taken lightly. We haven't even bumped the default format for old lock files to `V2` yet, they're still on `V1`. Hopefully in getting this in early-ish, though, we can at least get the ball rolling.
projects / cargo.git / log