Auto merge of #6687 - dwijnand:cosmetic-2, r=dwijnand

Various cosmetic improvements

Resubmit of #6673 which, somehow, broke.
cc @alexreg

Author: bors

ARCHITECTURE.md

@@ -5,7 +5,7 @@ find it useful if you want to contribute to Cargo or if you are
 interested in the inner workings of Cargo.
 
 The purpose of Cargo is to formalize a canonical Rust workflow, by automating
-the standard tasks associated with distributing software.  Cargo simplifies
+the standard tasks associated with distributing software. Cargo simplifies
 structuring a new project, adding dependencies, writing and running unit tests,
 and more.
 
@@ -58,7 +58,7 @@ the local hard drive.
 
 `Resolve` is the representation of a directed acyclic graph of package
 dependencies, which uses `PackageId`s for nodes. This is the data
-structure that is saved to the lock file. If there is no lockfile,
+structure that is saved to the lock file. If there is no lock file,
 Cargo constructs a resolve by finding a graph of packages which
 matches declared dependency specification according to semver.
 
@@ -118,14 +118,14 @@ to nightly rustc).
 
 Cargo uses [`env_logger`](https://docs.rs/env_logger/*/env_logger/), so you can set
 `RUST_LOG` environment variable to get the logs. This is useful both for diagnosing
-bugs in stable Cargo and for local development. Cargo also has internal hierarchical 
-profiling infrastructure, which is activated via `CARGO_PROFILE` variable 
+bugs in stable Cargo and for local development. Cargo also has internal hierarchical
+profiling infrastructure, which is activated via `CARGO_PROFILE` variable
 
 ```
-# Outputs all logs with levels debug and higher  
+# Outputs all logs with levels debug and higher
 $ RUST_LOG=debug cargo generate-lockfile
 
-# Don't forget that you can filter by module as well 
+# Don't forget that you can filter by module as well
 $ RUST_LOG=cargo::core::resolver=trace cargo generate-lockfile
 
 # Output first three levels of profiling info

CONTRIBUTING.md

@@ -86,7 +86,7 @@ working on.
 * Include tests that cover all non-trivial code. The existing tests
 in `test/` provide templates on how to test Cargo's behavior in a
 sandbox-environment. The internal module `testsuite/support` provides a vast amount
-of helpers to minimize boilerplate.  See [`testsuite/support/mod.rs`] for an
+of helpers to minimize boilerplate. See [`testsuite/support/mod.rs`] for an
 introduction to writing tests.
 * Make sure `cargo test` passes. If you do not have the cross-compilers
 installed locally, install them using the instructions returned by
@@ -110,7 +110,7 @@ weekends. If you don't get a reply, you may poke the core developers on [Discord
 
 A merge of Cargo's master-branch and your changes is immediately queued
 to be tested after the pull request is made. In case unforeseen
-problems are discovered during this step (e.g. a failure on a platform you
+problems are discovered during this step (e.g., a failure on a platform you
 originally did not develop on), you may ask for guidance. Push additional
 commits to your branch to tackle these problems.
 

src/bin/cargo/commands/bench.rs

@@ -46,14 +46,14 @@ pub fn cli() -> App {
         ))
         .after_help(
             "\
-The benchmark filtering argument `BENCHNAME` and all the arguments following the
+The benchmark filtering argument BENCHNAME and all the arguments following the
 two dashes (`--`) are passed to the benchmark binaries and thus to libtest
-(rustc's built in unit-test and micro-benchmarking framework).  If you're
+(rustc's built in unit-test and micro-benchmarking framework). If you're
 passing arguments to both Cargo and the binary, the ones after `--` go to the
-binary, the ones before go to Cargo.  For details about libtest's arguments see
+binary, the ones before go to Cargo. For details about libtest's arguments see
 the output of `cargo bench -- --help`.
 
-If the --package argument is given, then SPEC is a package id specification
+If the `--package` argument is given, then SPEC is a package ID specification
 which indicates which package should be benchmarked. If it is not given, then
 the current package is benchmarked. For more information on SPEC and its format,
 see the `cargo help pkgid` command.
@@ -62,7 +62,7 @@ All packages in the workspace are benchmarked if the `--all` flag is supplied. T
 `--all` flag is automatically assumed for a virtual manifest.
 Note that `--exclude` has to be specified in conjunction with the `--all` flag.
 
-The --jobs argument affects the building of the benchmark executable but does
+The `--jobs` argument affects the building of the benchmark executable but does
 not affect how many jobs are used when running the benchmarks.
 
 Compilation can be customized with the `bench` profile in the manifest.

src/bin/cargo/commands/check.rs

@@ -34,7 +34,7 @@ pub fn cli() -> App {
         .arg_message_format()
         .after_help(
             "\
-If the --package argument is given, then SPEC is a package id specification
+If the `--package` argument is given, then SPEC is a package ID specification
 which indicates which package should be built. If it is not given, then the
 current package is built. For more information on SPEC and its format, see the
 `cargo help pkgid` command.
@@ -45,7 +45,7 @@ Note that `--exclude` has to be specified in conjunction with the `--all` flag.
 
 Compilation can be configured via the use of profiles which are configured in
 the manifest. The default profile for this command is `dev`, but passing
-the --release flag will use the `release` profile instead.
+the `--release` flag will use the `release` profile instead.
 
 The `--profile test` flag can be used to check unit tests with the
 `#[cfg(test)]` attribute.

src/bin/cargo/commands/clean.rs

@@ -13,7 +13,7 @@ pub fn cli() -> App {
         .arg_doc("Whether or not to clean just the documentation directory")
         .after_help(
             "\
-If the --package argument is given, then SPEC is a package id specification
+If the `--package` argument is given, then SPEC is a package ID specification
 which indicates which package's artifacts should be cleaned out. If it is not
 given, then all packages' artifacts are removed. For more information on SPEC
 and its format, see the `cargo help pkgid` command.

src/bin/cargo/commands/doc.rs

@@ -37,7 +37,7 @@ All packages in the workspace are documented if the `--all` flag is supplied. Th
 `--all` flag is automatically assumed for a virtual manifest.
 Note that `--exclude` has to be specified in conjunction with the `--all` flag.
 
-If the --package argument is given, then SPEC is a package id specification
+If the `--package` argument is given, then SPEC is a package ID specification
 which indicates which package should be documented. If it is not given, then the
 current package is documented. For more information on SPEC and its format, see
 the `cargo help pkgid` command.

src/bin/cargo/commands/fetch.rs

@@ -10,13 +10,13 @@ pub fn cli() -> App {
         .arg_target_triple("Fetch dependencies for the target triple")
         .after_help(
             "\
-If a lockfile is available, this command will ensure that all of the git
+If a lock file is available, this command will ensure that all of the Git
 dependencies and/or registries dependencies are downloaded and locally
 available. The network is never touched after a `cargo fetch` unless
-the lockfile changes.
+the lock file changes.
 
-If the lockfile is not available, then this is the equivalent of
-`cargo generate-lockfile`. A lockfile is generated and dependencies are also
+If the lock file is not available, then this is the equivalent of
+`cargo generate-lockfile`. A lock file is generated and dependencies are also
 all updated.
 ",
         )

src/bin/cargo/commands/install.rs

@@ -63,13 +63,13 @@ enables overwriting existing binaries. Thus you can reinstall a crate with
 
 Omitting the <crate> specification entirely will
 install the crate in the current directory. That is, `install` is equivalent to
-the more explicit `install --path .`.  This behaviour is deprecated, and no
+the more explicit `install --path .`. This behaviour is deprecated, and no
 longer supported as of the Rust 2018 edition.
 
 If the source is crates.io or `--git` then by default the crate will be built
-in a temporary target directory.  To avoid this, the target directory can be
+in a temporary target directory. To avoid this, the target directory can be
 specified by setting the `CARGO_TARGET_DIR` environment variable to a relative
-path.  In particular, this can be useful for caching build artifacts on
+path. In particular, this can be useful for caching build artifacts on
 continuous integration systems.",
         )
 }

src/bin/cargo/commands/pkgid.rs

@@ -6,11 +6,11 @@ pub fn cli() -> App {
     subcommand("pkgid")
         .about("Print a fully qualified package specification")
         .arg(Arg::with_name("spec"))
-        .arg_package("Argument to get the package id specifier for")
+        .arg_package("Argument to get the package ID specifier for")
         .arg_manifest_path()
         .after_help(
             "\
-Given a <spec> argument, print out the fully qualified package id specifier.
+Given a <spec> argument, print out the fully qualified package ID specifier.
 This command will generate an error if <spec> is ambiguous as to which package
 it refers to in the dependency graph. If no <spec> is given, then the pkgid for
 the local package is printed.

src/bin/cargo/commands/rustdoc.rs

@@ -1,7 +1,7 @@
-use crate::command_prelude::*;
-
 use cargo::ops::{self, DocOptions};
 
+use crate::command_prelude::*;
+
 pub fn cli() -> App {
     subcommand("rustdoc")
         .setting(AppSettings::TrailingVarArg)
@@ -34,13 +34,13 @@ pub fn cli() -> App {
         .after_help(
             "\
 The specified target for the current package (or package specified by SPEC if
-provided) will be documented with the specified <opts>... being passed to the
+provided) will be documented with the specified `<opts>...` being passed to the
 final rustdoc invocation. Dependencies will not be documented as part of this
-command.  Note that rustdoc will still unconditionally receive arguments such
-as -L, --extern, and --crate-type, and the specified <opts>...  will simply be
-added to the rustdoc invocation.
+command. Note that rustdoc will still unconditionally receive arguments such
+as `-L`, `--extern`, and `--crate-type`, and the specified `<opts>...` will
+simply be added to the rustdoc invocation.
 
-If the --package argument is given, then SPEC is a package id specification
+If the `--package` argument is given, then SPEC is a package ID specification
 which indicates which package should be documented. If it is not given, then the
 current package is documented. For more information on SPEC and its format, see
 the `cargo help pkgid` command.

src/bin/cargo/commands/test.rs

@@ -1,10 +1,10 @@
-use crate::command_prelude::*;
-
 use cargo::ops::{self, CompileFilter};
 
+use crate::command_prelude::*;
+
 pub fn cli() -> App {
     subcommand("test")
-        // subcommand aliases are handled in aliased_command()
+        // Subcommand aliases are handled in `aliased_command()`.
         // .alias("t")
         .setting(AppSettings::TrailingVarArg)
         .about("Execute all unit and integration tests and build examples of a local package")
@@ -47,17 +47,17 @@ pub fn cli() -> App {
         .arg_message_format()
         .after_help(
             "\
-The test filtering argument `TESTNAME` and all the arguments following the
+The test filtering argument TESTNAME and all the arguments following the
 two dashes (`--`) are passed to the test binaries and thus to libtest
-(rustc's built in unit-test and micro-benchmarking framework).  If you're
+(rustc's built in unit-test and micro-benchmarking framework). If you're
 passing arguments to both Cargo and the binary, the ones after `--` go to the
-binary, the ones before go to Cargo.  For details about libtest's arguments see
-the output of `cargo test -- --help`.  As an example, this will run all
+binary, the ones before go to Cargo. For details about libtest's arguments see
+the output of `cargo test -- --help`. As an example, this will run all
 tests with `foo` in their name on 3 threads in parallel:
 
     cargo test foo -- --test-threads 3
 
-If the --package argument is given, then SPEC is a package id specification
+If the `--package` argument is given, then SPEC is a package ID specification
 which indicates which package should be tested. If it is not given, then the
 current package is tested. For more information on SPEC and its format, see the
 `cargo help pkgid` command.
@@ -66,9 +66,9 @@ All packages in the workspace are tested if the `--all` flag is supplied. The
 `--all` flag is automatically assumed for a virtual manifest.
 Note that `--exclude` has to be specified in conjunction with the `--all` flag.
 
-The --jobs argument affects the building of the test executable but does
+The `--jobs` argument affects the building of the test executable but does
 not affect how many jobs are used when running the tests. The default value
-for the --jobs argument is the number of CPUs. If you want to control the
+for the `--jobs` argument is the number of CPUs. If you want to control the
 number of simultaneous running test cases, pass the `--test-threads` option
 to the test binaries:
 
@@ -77,7 +77,7 @@ to the test binaries:
 Compilation can be configured via the `test` profile in the manifest.
 
 By default the rust test harness hides output from test execution to
-keep results readable. Test output can be recovered (e.g. for debugging)
+keep results readable. Test output can be recovered (e.g., for debugging)
 by passing `--nocapture` to the test binaries:
 
     cargo test -- --nocapture
@@ -130,8 +130,8 @@ pub fn exec(config: &mut Config, args: &ArgMatches<'_>) -> CliResult {
         compile_opts,
     };
 
-    // TESTNAME is actually an argument of the test binary, but it's
-    // important so we explicitly mention it and reconfigure
+    // `TESTNAME` is actually an argument of the test binary, but it's
+    // important, so we explicitly mention it and reconfigure.
     let mut test_args = vec![];
     test_args.extend(args.value_of("TESTNAME").into_iter().map(|s| s.to_string()));
     test_args.extend(

src/bin/cargo/commands/uninstall.rs

@@ -11,7 +11,7 @@ pub fn cli() -> App {
         .arg(opt("root", "Directory to uninstall packages from").value_name("DIR"))
         .after_help(
             "\
-The argument SPEC is a package id specification (see `cargo help pkgid`) to
+The argument SPEC is a package ID specification (see `cargo help pkgid`) to
 specify which crate should be uninstalled. By default all binaries are
 uninstalled for a crate but the `--bin` and `--example` flags can be used to
 only uninstall particular binaries.

src/bin/cargo/commands/update.rs

@@ -21,10 +21,10 @@ This command requires that a `Cargo.lock` already exists as generated by
 If SPEC is given, then a conservative update of the lockfile will be
 performed. This means that only the dependency specified by SPEC will be
 updated. Its transitive dependencies will be updated only if SPEC cannot be
-updated without updating dependencies.  All other dependencies will remain
+updated without updating dependencies. All other dependencies will remain
 locked at their currently recorded versions.
 
-If PRECISE is specified, then --aggressive must not also be specified. The
+If PRECISE is specified, then `--aggressive` must not also be specified. The
 argument PRECISE is a string representing a precise revision that the package
 being updated should be updated to. For example, if the package comes from a git
 repository, then PRECISE would be the exact revision that the repository should
@@ -33,7 +33,7 @@ be updated to.
 If SPEC is not given, then all dependencies will be re-resolved and
 updated.
 
-For more information about package id specifications, see `cargo help pkgid`.
+For more information about package ID specifications, see `cargo help pkgid`.
 ",
         )
 }