Merge branch 'stable'

Author: mpilgrem

CONTRIBUTING.md

@@ -39,8 +39,8 @@ improvements, and feature enhancements.
 Maintainers should be included in discussions of controversial changes and
 tricky code changes.
 
-Our general approach is **"it's easier to ask forgiveness than permission"**. If
-there is ever a bad change, it can always be rolled back.
+Our general approach is **"it is easier to ask forgiveness than permission"**.
+If there is ever a bad change, it can always be rolled back.
 
 ### Stack's maintainers
 
@@ -318,11 +318,11 @@ used for that purpose.
 ## Code
 
 If you would like to contribute code to fix a bug, add a new feature, or
-otherwise improve `stack`, pull requests are most welcome. It's a good idea to
+otherwise improve `stack`, pull requests are most welcome. It is a good idea to
 [submit an issue](https://github.com/commercialhaskell/stack/issues/new) to
 discuss the change before plowing into writing code.
 
-If you'd like to help out but aren't sure what to work on, look for issues with
+If you'd like to help out but are not sure what to work on, look for issues with
 the
 [awaiting pull request](https://github.com/commercialhaskell/stack/issues?q=is%3Aopen+is%3Aissue+label%3A%22awaiting+pull+request%22)
 label. Issues that are suitable for newcomers to the codebase have the
@@ -509,10 +509,10 @@ stack test
 ~~~
 
 The `--file-watch` is a very useful option to get quick feedback. However,
-running the entire test suite after each file change will slow you down. You'll
-need to specify which test suite (unit test or integration) and pass arguments
-to specify which module you'd specifically like to run to get quick feedback. A
-description of this follows below.
+running the entire test suite after each file change will slow you down. You
+will need to specify which test suite (unit test or integration) and pass 
+arguments to specify which module you'd specifically like to run to get quick 
+feedback. A description of this follows below.
 
 
 If you would like to run the unit tests on their own, you can command:
@@ -545,7 +545,7 @@ Integration tests can be found in the
 [tests/integration](https://github.com/commercialhaskell/stack/tree/master/tests/integration)
 folder.
 
-Running the integration tests is a little involved, you'll need to command:
+Running the integration tests is a little involved, you will need to command:
 
 ~~~text
 stack build --flag stack:integration-tests stack --exec stack-integration-test
@@ -579,8 +579,8 @@ You can disable a few integration tests through the -n option :
 stack build --flag stack:integration-tests stack --exec "stack-integration-test -n <PATTERN1> -n <PATTERN2>"
 ~~~
 
-To disable folders named after `<PATTERN1>` and `<PATTERN2>`
-It's especially useful when some tests are taking a while to complete.
+to disable folders named after `<PATTERN1>` and `<PATTERN2>`. It is especially
+useful when some tests are taking a while to complete.
 
 On Linux, the `stack-integration-test` executable uses the `lld` linker and
 expects it to be on the PATH. The integration tests complete significantly
@@ -823,7 +823,7 @@ For further information, see the documentation for
 
 ## Slack channel
 
-If you're making deep changes and real-time communication with the Stack team
+If you are making deep changes and real-time communication with the Stack team
 would be helpful, we have a `#stack-collaborators` Slack channel in the
 Haskell Foundation workspace. To join the workspace, follow this
 [link](https://haskell-foundation.slack.com/join/shared_invite/zt-z45o9x38-8L55P27r12YO0YeEufcO2w#/shared-invite/email).

ChangeLog.md

@@ -243,8 +243,8 @@ stack exec my-project-exe # (4)!
 3.  Build the template project and create an executable named `my-project-exe`.
 
     First, if necessary, Stack will download a version of GHC in an isolated
-    location. That won't interfere with other GHC installations on your system.
-    (On Windows, if necessary, Stack will also download
+    location. That will not interfere with other GHC installations on your 
+    system. (On Windows, if necessary, Stack will also download
     [MSYS2](https://www.msys2.org/). MSYS2 is a project that provides popular
     tools for developers on Windows.)
 

doc/README.md

@@ -94,8 +94,8 @@ in CLI).
   snapshot packages that have been replaced.
 * Apply the `flags` and `ghc-options` by name to these packages overwriting
   any previous values coming from a snapshot. If any values are specified
-  but no matching package is found, it's an error. If a flag is not defined
-  in the corresponding package cabal file, it's an error.
+  but no matching package is found, it is an error. If a flag is not defined
+  in the corresponding package cabal file, it is an error.
 * We are now left with the following:
     * A wanted compiler version
     * A map from package name to immutable packages with package config (flags,
@@ -160,13 +160,13 @@ specific components).
 
 Named CLI flags are applied to specific packages by updating the
 config in one of the four maps. If a flag is specified and no package
-is found, it's an error. Note that flag settings are added _on top of_
+is found, it is an error. Note that flag settings are added _on top of_
 previous settings in this case, and does not replace them. That is, if
 previously we have `singleton (FlagName "foo") True` and now add
 `singleton (FlagName "bar") True`, both `foo` and `bar` will now be
 true. If any flags are specified but no matching package is found,
-it's an error. If a flag is not defined in the corresponding package
-cabal file, it's an error.
+it is an error. If a flag is not defined in the corresponding package
+Cabal file, it is an error.
 
 ## Apply CLI GHC options
 
@@ -182,7 +182,7 @@ project package which uses that flag name.
 
 General options are divided into the following categories:
 
-* `$locals` is deprecated, it's now a synonym for `$project`
+* `$locals` is deprecated, it is now a synonym for `$project`
 * `$project` applies to all project packages, not to any dependencies
 * `$targets` applies to all project packages that are targets, not to any
   dependencies or non-target project packages. This is the default option
@@ -199,9 +199,8 @@ they get prepended otherwise they get used as is.
 Use some deterministic binary serialization and SHA256 thereof to get
 a hash of the following information:
 
-* Actual compiler (GHC version, path, *FIXME* probably some other
-  unique info from GHC, I've heard that `ghc --info` gives you
-  something)
+* Actual compiler (GHC version, path, *FIXME* probably some other unique info 
+  from GHC, I have heard that `ghc --info` gives you something)
 * Global database map
 * Immutable dependency map
 
@@ -234,19 +233,19 @@ installed in this database will never need to be rebuilt.
   all enabled components (using the fun backwards compat logic for
   `build-tools`)
 * Apply the logic recursively to come up with a full build plan
-* If a task depends exclusively on immutable packages, mark it as
-  immutable. Otherwise, it's mutable. The former go into the snapshot
-  database, the latter into the local database.
+* If a task depends exclusively on immutable packages, mark it as immutable. 
+  Otherwise, it is mutable. The former go into the snapshot database, the latter
+  into the local database.
 
 We now have a set of tasks of packages/components to build, with full
 config information for each package, and dependencies that must be
 built first.
 
 !!! bug "To do"
 
-    There's some logic to deal with cyclic dependencies between test suites and
+    There is some logic to deal with cyclic dependencies between test suites and
     benchmarks, where a task can be broken up into individual components versus
-    be kept as a single task. Need to document this better. Currently it's the
+    be kept as a single task. Need to document this better. Currently it is the
     "all in one" logic.
 
 ## Unregister local modified packages
@@ -269,7 +268,7 @@ built first.
 * If all good: do nothing
 * Otherwise, for immutable tasks: check the precompiled cache for an
   identical package installation (same GHC, dependencies, etc). If
-  present: copy that over, and we're done.
+  present: copy that over, and we are done.
 * Otherwise, perform the build, register, write to the Stack specific
   "is installed" stuff, and (for immutable tasks) register to the
   precompiled cache

doc/build_overview.md

@@ -334,7 +334,7 @@ This overrides:
 
 Default: Disabled
 
-Set the flag to force rebuild of packages even when it doesn't seem necessary
+Set the flag to force rebuild of packages even when it does not seem necessary
 based on file dirtiness.
 
 ### `--[no-]haddock` flag
@@ -530,7 +530,7 @@ Default (`stack build`): Disabled
 Default (`stack test` or `stack bench`): Enabled
 
 Set the flag to continue building packages even after some build step fails.
-The packages which depend upon the failed build won't get built.
+The packages which depend upon the failed build will not get built.
 
 ### `--[no-]keep-tmp-files` flag
 
@@ -571,7 +571,7 @@ with other projects.
 
 Default: Disabled
 
-Set the flag to force reconfiguration even when it doesn't seem necessary based
+Set the flag to force reconfiguration even when it does not seem necessary based
 on file dirtiness. This is sometimes useful with custom `Setup.hs` files, in
 particular when they depend on external data files.
 
@@ -581,7 +581,7 @@ particular when they depend on external data files.
 project package. It allows you to skip test suites and benchmark without
 specifying other components (e.g. `stack test --skip long-test-suite` will run
 the tests without the `long-test-suite` test suite). Be aware that skipping
-executables won't work the first time the package is built due to an issue in
+executables will not work the first time the package is built due to an issue in
 [Cabal](https://github.com/commercialhaskell/stack/issues/3229).
 
 This option can be specified multiple times to skip multiple components.

doc/commands/build_command.md

@@ -94,13 +94,13 @@ By default:
 
         The `--only-main` flag can be useful if:
 
-        1.  You're loading the project in order to run it in GHCi (e.g. via
+        1.  You are loading the project in order to run it in GHCi (e.g. via
             `main`), and you intend to reload while developing. Without flag,
             you will need to quit and restart GHCi whenever a module gets
             deleted. With the flag, reloading should work fine in this case.
 
-        2.  If many of your modules have exports named the same thing, then
-            you'll need to refer to them using qualified names. To avoid this,
+        2.  If many of your modules have exports named the same thing, then you 
+            will need to refer to them using qualified names. To avoid this,
             use the `--only-main` flag to start with a blank slate and just
             import the modules you are interested in.
 
@@ -114,7 +114,7 @@ Stack combines all of the GHC options of components.
 
     Combining GHC options should work out when packages share similar
     conventions. However, conflicts may arise, such as when one component
-    defines default extensions which aren't assumed by another. For example,
+    defines default extensions which are not assumed by another. For example,
     specifying `NoImplicitPrelude` in one component but not another is likely to
     cause failures. GHCi will be run with `-XNoImplicitPrelude`, but it is
     likely that modules in the other component assume that the `Prelude` is
@@ -156,7 +156,7 @@ and so will have access to your databases.
 
 !!! note
 
-    Running `stack ghci` on a pristine copy of the code doesn't currently build
+    Running `stack ghci` on a pristine copy of the code does not currently build
     libraries
     (issue [#2790](https://github.com/commercialhaskell/stack/issues/2790)) or
     internal libraries

doc/commands/ghci_command.md

@@ -67,7 +67,7 @@ This will output to the standard output stream a summary report for the combined
 coverage from `A` and `B`'s test suites. It will also log the path to the HTML
 for the corresponding full report.
 
-This command also supports taking extra `.tix` files.  If you've also built an
+This command also supports taking extra `.tix` files.  If you have also built an
 executable, against exactly the same library versions of `A`, `B`, and `C`, then
 you could command the following:
 
@@ -95,7 +95,7 @@ This report will consider all test results as well as the newly generated
 2.  These test suites link against your library, rather than building the
     library directly. Coverage information is only given for libraries, ignoring
     the modules which get compiled directly into your executable. A common case
-    where this doesn't happen is when your test suite and library both have
+    where this does not happen is when your test suite and library both have
     something like `hs-source-dirs: src/`. In this case, when building your test
     suite you may also be compiling your library, instead of just linking
     against it.
@@ -140,8 +140,8 @@ However, advanced users may want to understand exactly how `--coverage` works:
    will then get loaded, modified, and outputted to
    `pkg-name/test-name/test-name.tix` in the local HPC root directory.
 
-   The `.tix` file gets modified to remove coverage file that isn't associated
-   with a library. So, this means that you won't get coverage information for
+   The `.tix` file gets modified to remove coverage file that is not associated
+   with a library. So, this means that you will not get coverage information for
    the modules compiled in the `executable` or `test-suite` stanza of your Cabal
    file. This makes it possible to directly union multiple `*.tix` files from
    different executables (assuming they are using the exact same versions of the

doc/commands/hpc_command.md

@@ -27,7 +27,7 @@ mechanisms reflect distinct concepts, namely:
   installation.
 
 When `install-ghc: false`, the script is still run. That allows you to ensure
-that only your script will install GHC and Stack won't default to its own
+that only your script will install GHC and Stack will not default to its own
 installation logic, even when the script fails.
 
 The following environment variables are always available to the script:
@@ -61,7 +61,7 @@ case $HOOK_GHC_TYPE in
 		#   command install $HOOK_GHC_VERSION >/dev/null
 		;;
 	git)
-		>&2 echo "Hook doesn't support installing from source"
+		>&2 echo "Hook does not support installing from source"
 		exit 1
 		;;
 	*)
@@ -89,7 +89,7 @@ case $HOOK_GHC_TYPE in
         ;;
     git)
         # TODO: should be somewhat possible
-        >&2 echo "Hook doesn't support installing from source"
+        >&2 echo "Hook does not support installing from source"
         exit 1
         ;;
     *)

doc/configure/customisation_scripts.md

@@ -1,5 +1,5 @@
 ---
-Title: Configure
+title: Configure
 ---
 <div class="hidden-warning"><a href="https://docs.haskellstack.org/"><img src="https://cdn.jsdelivr.net/gh/commercialhaskell/stack/doc/img/hidden-warning.svg"></a></div>
 

doc/configure/index.md

@@ -337,7 +337,7 @@ compiler-repository: git://my/ghc/repository
 ~~~
 
 Stack does not check the compiler version when it uses a compiler built from
-source. It is assumed that the built compiler is recent enough as Stack doesn't
+source. It is assumed that the built compiler is recent enough as Stack does not
 enable any known workaround to make older compilers work.
 
 Building the compiler can take a very long time (more than one hour). For faster
@@ -595,7 +595,7 @@ The value of the `dump-logs` key controls what, if any, log file content is sent
 Possible values are:
 
 ~~~yaml
-dump-logs: none    # don't dump the content of any log files
+dump-logs: none    # do not dump the content of any log files
 dump-logs: warning # dump the content of any log files that include GHC warnings
 dump-logs: all     # dump the content of all log files
 ~~~
@@ -1608,7 +1608,7 @@ Default: `false`, unless the [Docker](../../topics/docker_integration.md) or
 Command line equivalent (takes precedence): `--[no-]system-ghc` flag
 
 Enables or disables using the GHC available on the PATH. (Make sure PATH is
-explicit, i.e., don't use ~.) Useful to enable if you want to save the time,
+explicit, i.e., do not use ~.) Useful to enable if you want to save the time,
 bandwidth or storage space needed to setup an isolated GHC.
 
 In a Nix-enabled configuration, Stack is incompatible with `system-ghc: false`.