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.
Auto merge of #8543 - CPerezz:manifest_edition_nit, r=Eh2406
Cargo book nitpick in Manifest section
The Manifest section states on the example that the
default edition is 2018, but the lines of text above
state that the default is `2015` which is not correct.
The Manifest section states on the example that the
default edition is 2018, but the lines of text avobe
state that the default is `2015` which is not correct.
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.
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
sepparated `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 defaut.
Alex Crichton [Mon, 20 Jul 2020 21:50:49 +0000 (14:50 -0700)]
Warn if `master` unifies with `DefaultBranch`
This commit implements a simple warning to indicate when `DefaultBranch`
is unified with `Branch("master")`, meaning `Cargo.toml` inconsistently
lists `branch = "master"` and not. The intention here is to ensure that
all projects uniformly use one or the other to ensure we can smoothly
transition to the new lock file format.
Alex Crichton [Mon, 20 Jul 2020 17:11:25 +0000 (10:11 -0700)]
Plan for a V3 lockfile format
This commit lays the groundwork for an eventual V3 of the lock file
format. The changes in this format are:
* A `version` indicator will be at the top of the file so we don't have
to guess what format the lock is in, we know for sure. Additionally
Cargo now reading a super-from-the-future lock file format will give a
better error.
* Git dependencies with `Branch("master")` will be encoded with
`?branch=master` instead of with nothing.
The motivation for this change is to eventually switch Cargo's
interpretation of default git branches.
Alex Crichton [Mon, 20 Jul 2020 16:28:35 +0000 (09:28 -0700)]
Warn when default branch is not `master`
This commit implements a warning in Cargo for when a dependency
directive is using `DefaultBranch` but the default branch of the remote
repository is not actually `master`. We will eventually break this
dependency directive and the warning indicates the fix, which is to
write down `branch = "master"`.
Alex Crichton [Mon, 20 Jul 2020 15:47:57 +0000 (08:47 -0700)]
Effectively revert #8364
This commit is intended to be an effective but not literal revert
of #8364. Internally Cargo will still distinguish between
`DefaultBranch` and `Branch("master")` when reading `Cargo.toml` files,
but for almost all purposes the two are equivalent. This will namely fix
the issue we have with lock file encodings where both are encoded with
no `branch` (and without a branch it's parsed from a lock file as
`DefaultBranch`).
This will preserve the change that `cargo vendor` will not print out
`branch = "master"` annotations but that desugars to match the lock file
on the other end, so it should continue to work.
Tests have been added in this commit for the regressions found on #8468.
Auto merge of #8530 - ehuss:ci-force-curl, r=alexcrichton
Update features set in CI.
This removes the `curl/force-system-lib-on-osx` feature, which I don't think has been needed for a while (I believe it was fixed with https://github.com/alexcrichton/curl-rust/pull/283).
This also uses the same features for `test -p cargo-test-support` so that cargo doesn't get recompiled (saving about a minute).
Mask out system core.autocrlf settings before resetting git repos
This fixes an issue the gecko developers noticed when vendoring
on windows. \[0\] If a user has `core.autocrlf=true` set
(a reasonable default on windows), vendoring from a git source
would cause all the newlines to be rewritten to include carriage
returns, creating churn and platform-specific results.
To fix this, we simply set the global cargo checkout's "local"
core.autocrlf value before performing a `reset`. This masks out
the system configuration without interfering with the user's
own system/project settings.
Auto merge of #8515 - Spanfile:target-triple-opt-help-fix, r=ehuss
Fix the help display for the target-triple option
The `--target` option (in `cargo build` for example) had its value name and help text flipped, so it looked like;
```
--target <Build for the target triple>... TRIPLE
```
This PR swaps the `value_name` and `help` arguments for the `multi_opt` call in `command_prelude.rs`/`fn arg_target_triple()` so the value name and help text are displayed correctly.
Auto merge of #8511 - eonil:check-member-path-existence, r=ehuss
Check workspace member existence as dir.
Cargo command fails if workspace members are set to something like `crates/*` and if there's any non project file in `crates` directory. This PR makes member discovery logic to exclude non-directory paths.
In my case, `.DS_Store` (which is made automatically by Finder on macOS) file triggered this issue.
Mask out system core.autocrlf settings before resetting git repos
This fixes an issue the gecko developers noticed when vendoring
on windows. [0] If a user has `core.autocrlf=true` set
(a reasonable default on windows), vendoring from a git source
would cause all the newlines to be rewritten to include carriage
returns, creating churn and platform-specific results.
To fix this, we simply set the global cargo checkout's "local"
core.autocrlf value before performing a `reset`. This masks out
the system configuration without interfering with the user's
own system/project settings.
Auto merge of #8500 - alexcrichton:build-override-opt-level-0, r=Eh2406
Build host dependencies with opt-level 0 by default
This commit updates Cargo's build of host dependencies to build them
with optimization level 0 by default instead of matching the profile of
the final binary.
Since Cargo's inception build dependencies have, by default, been built
in a profile that largely matches the profile of the final target
artifact. Build dependencies, however, rarely actually need to be
optimized and are often executing very small tasks, which means that
optimizing them often wastes a lot of build time. A great example of
this is procedural macros where `syn` and friends are pretty heavyweight
to optimize, and the amount of Rust code they're parsing is typically
quite small, so the time spent optimizing rarely comes as a benefit.
The goal of this PR is to improve build times on average in the
community by not spending time optimizing build dependencies (build
scripts, procedural macros, and their transitive dependencies). The PR
will not be a universal win for everyone, however. There's some
situations where your build time may actually increase:
* In some cases build scripts and procedural macros can take quite a
long time to run!
* Cargo may not build dependencies more than once if they're shared with
the main build. This only applies to builds without `--target` where
the same crate is used in the final binary as in a build script.
In these cases, however, the `build-override` profile has existed for
some time know and allows giving a knob to tweak this behavior. For
example to get back the previous build behavior of Cargo you would
specify, in `Cargo.toml`:
There are two notable features we would like to add in the future which
would make the impact of a change like this smaller, but they're not
implemented at this time (nor do we have concrete plans to implement
them). First we would like crates to have a way of specifying they
should be optimized by default, despite default profile options. Often
crates, like lalrpop historically, have abysmal performance in debug
mode and almost always (even in debug builds) want to be built in
release mode. The second feature is that ideally crate authors would be
able to tell Cargo to minimize the number of crates built, unifying
profiles where possible to avoid double-compiling crates.
At this time though the Cargo team feels that the benefit of changing
the defaults is well worth this change. Neither today nor directly after
this change will be a perfect world, but it's hoped that this change
makes things less bad!
projects / cargo.git / log