Merge branch 'master' into https_all_the_things

Author: Jonathan Claudius

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/cli.rs

@@ -194,7 +194,7 @@ Some common cargo commands are (see all commands with --list):
     doc         Build this package's and its dependencies' documentation
     new         Create a new cargo package
     init        Create a new cargo package in an existing directory
-    run         Build and execute src/main.rs
+    run         Run a binary or example of the local package
     test        Run the tests
     bench       Run the benchmarks
     update      Update dependencies listed in Cargo.lock

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

@@ -7,13 +7,13 @@ pub fn cli() -> App {
         .about("Remove artifacts that cargo has generated in the past")
         .arg_package_spec_simple("Package to clean artifacts for")
         .arg_manifest_path()
-        .arg_target_triple("Target triple to clean output for (default all)")
+        .arg_target_triple("Target triple to clean output for")
         .arg_target_dir()
         .arg_release("Whether or not to clean release artifacts")
         .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.