Merge pull request #6452 from commercialhaskell/lts-22.7

Bump Stack to GHC 9.6.4/lts-22.7

Author: mpilgrem

.devcontainer/devcontainer.json

@@ -3,8 +3,8 @@
   "build": {
     "dockerfile": "GHC.Dockerfile",
     "args": {
-      "GHC_VERSION": "9.6.3",
-      "HLS_VERSION": "2.5.0.0",
+      "GHC_VERSION": "9.6.4",
+      "HLS_VERSION": "2.6.0.0",
       "USE_ZSH_FOR_ROOT": "unset-to-use-ash",
       "SET_LANG": "C.UTF-8",
       "SET_TZ": ""

.github/workflows/integration-tests.yml

@@ -33,13 +33,13 @@ jobs:
         include:
         - os: ubuntu-latest
           release-args: "--alpine"
-          cache-bust: "2023-10-11"
+          cache-bust: "2024-01-20"
         - os: windows-latest
           release-args: ""
-          cache-bust: "13"
+          cache-bust: "2024-01-20"
         - os: macos-latest
           release-args: ""
-          cache-bust: "23"
+          cache-bust: "2024-01-20"
     steps:
     - name: Clone project
       uses: actions/checkout@v3

.github/workflows/stan.yml

@@ -23,7 +23,7 @@ jobs:
       run: |
         git clone https://github.com/kowainik/stan.git
         cd stan
-        stack --compiler ghc-9.6.3 --local-bin-path ../.bin install
+        stack --compiler ghc-9.6.4 --local-bin-path ../.bin install
         cd ..
 
     - name: Generate .hie for analysis

CONTRIBUTING.md

@@ -606,7 +606,7 @@ for each file.
 
 [Stan](https://hackage.haskell.org/package/stan) is a Haskell static analysis
 tool. As of `stan-0.1.0.1`, it supports GHC >= 9.6.3 and Stack is built with
-GHC 9.6.3. The tool is configured by the contents of the `.stan.toml` file.
+GHC 9.6.4. The tool is configured by the contents of the `.stan.toml` file.
 
 This workflow will run if:
 

ChangeLog.md

@@ -65,7 +65,7 @@ Other enhancements:
   `notify-if-cabal-untested` keys are introduced, to allow the notification to
   be muted if unwanted.
 * The compiler version is included in Stack's build message (e.g.
-  `stack> build (lib + exe + test) with ghc-9.6.3`).
+  `stack> build (lib + exe + test) with ghc-9.6.4`).
 * Add flag `--candidate` to Stack's `unpack` command, to allow package
   candidates to be unpacked locally.
 * Stack will notify the user if a specified architecture value is unknown to

cabal.config

@@ -189,7 +189,7 @@ constraints:
   , transformers-base ==0.4.6
   , transformers-compat ==0.7.2
   , typed-process ==0.2.11.1
-  , unix ==2.8.1.0
+  , unix ==2.8.4.0
   , unix-compat ==0.7.1
   , unix-time ==0.4.11
   , unliftio ==0.2.25.0

cabal.project

@@ -33,8 +33,8 @@
 -- specified by the snapshot specifed in Stack's project-level YAML
 -- configuration file (`stack.yaml`). The relevant version of GHC can be
 -- confirmed by reviewing the snapshot on Stackage. For example, at:
--- https://www.stackage.org/lts-22.6/cabal.config.
+-- https://www.stackage.org/lts-22.7/cabal.config.
 --
-with-compiler: ghc-9.6.3
+with-compiler: ghc-9.6.4
 import: cabal.config
 packages: .

doc/GUIDE.md

@@ -255,8 +255,8 @@ packages:
 
 The value of the `resolver` key tells Stack *how* to build your package: which
 GHC version to use, versions of package dependencies, and so on. Our value here
-says to use [LTS Haskell 22.6](https://www.stackage.org/lts-22.6), which
-implies GHC 9.6.3 (which is why `stack build` installs that version of GHC if it
+says to use [LTS Haskell 22.7](https://www.stackage.org/lts-22.7), which
+implies GHC 9.6.4 (which is why `stack build` installs that version of GHC if it
 is not already available to Stack). There are a number of values you can use for
 `resolver`, which we'll cover later.
 
@@ -503,7 +503,7 @@ also known as *snapshots*. We mentioned the LTS resolvers, and you can get quite
 a bit of information about it at
 [https://www.stackage.org/lts](https://www.stackage.org/lts), including:
 
-* The appropriate resolver value (`resolver: lts-22.6`, as is currently the
+* The appropriate resolver value (`resolver: lts-22.7`, as is currently the
   latest LTS)
 * The GHC version used
 * A full list of all packages available in this snapshot
@@ -522,7 +522,7 @@ towards by default as well).
 
 ## Resolvers and changing your compiler version
 
-Let's explore package sets a bit further. Instead of `lts-22.6`, let's change
+Let's explore package sets a bit further. Instead of `lts-22.7`, let's change
 our `stack.yaml` file to use the
 [latest nightly](https://www.stackage.org/nightly). Right now, this is currently
 2023-09-24 - please see the resolver from the link above to get the latest.
@@ -1340,7 +1340,7 @@ yields output like:
 
 ~~~text
 Run from outside a project, using implicit global project config
-Using latest snapshot resolver: lts-22.6
+Using latest snapshot resolver: lts-22.7
 Writing global (non-project-specific) config file to: /home/michael/.stack/global/stack.yaml
 Note: You can change the snapshot via the resolver field there.
 I installed the stm package via --package stm

doc/Stack_and_VS_Code.md

@@ -75,9 +75,9 @@ enabled). For further information about these options, see the `install-ghc`
 
 For this workaround to work, each time that a resolver is used that references a
 different version of GHC, then GHCup must be used to install it (if GHCup has
-not already installed that version). For example, to use `resolver: lts-22.6`
-(GHC 9.6.3), the command `ghcup install ghc 9.6.3` must have been used to
-install GHC 9.6.3. That may be a minor inconvenience for some people, as one the
+not already installed that version). For example, to use `resolver: lts-22.7`
+(GHC 9.6.4), the command `ghcup install ghc 9.6.4` must have been used to
+install GHC 9.6.4. That may be a minor inconvenience for some people, as one the
 primary benefits of Stack over other Haskell build tools has been that Stack
 automatically ensures that the necessary version of GHC is available.
 

doc/custom_snapshot.md

@@ -17,8 +17,8 @@ available in snapshots to ensure reproducibility.
     snapshot specification.
 
 ~~~yaml
-resolver: lts-22.6 # Inherits GHC version and package set
-compiler: ghc-9.6.2 # Overwrites GHC version in the resolver, optional
+resolver: lts-22.7 # Inherits GHC version and package set
+compiler: ghc-9.6.3 # Overwrites GHC version in the resolver, optional
 
 # Additional packages, follows extra-deps syntax
 packages:
@@ -61,35 +61,35 @@ custom snapshot, due to Stack sharing snapshot packages whenever possible.
 
 ### Overriding the compiler
 
-The following snapshot specification will be identical to `lts-22.6`, but
-instead use `ghc-9.6.2` instead of `ghc-9.6.3`:
+The following snapshot specification will be identical to `lts-22.7`, but
+instead use `ghc-9.6.3` instead of `ghc-9.6.4`:
 
 ~~~yaml
-resolver: lts-22.6
-compiler: ghc-9.6.2
+resolver: lts-22.7
+compiler: ghc-9.6.3
 ~~~
 
 ### Dropping packages
 
-The following snapshot specification will be identical to `lts-22.6`, but
+The following snapshot specification will be identical to `lts-22.7`, but
 without the `text` package in our snapshot. Removing this package will cause all
 the packages that depend on `text` to be unbuildable, but they will still be
 present in the snapshot.
 
 ~~~yaml
-resolver: lts-22.6
+resolver: lts-22.7
 drop-packages:
 - text
 ~~~
 
 ### Hiding packages
 
-The following snapshot specification will be identical to `lts-22.6`, but the
+The following snapshot specification will be identical to `lts-22.7`, but the
 `text` package will be hidden when registering. This will affect, for example,
 the import parser in the script command.
 
 ~~~yaml
-resolver: lts-22.6
+resolver: lts-22.7
 hidden:
 - text
 ~~~
@@ -99,11 +99,11 @@ hidden:
 In order to specify GHC options for a package, you use the same syntax as the
 [ghc-options](yaml_configuration.md#ghc-options) key for build configuration.
 
-The following snapshot specification will be identical to `lts-22.6`, but
+The following snapshot specification will be identical to `lts-22.7`, but
 provides `-O1` as a ghc-option for `text`:
 
 ~~~yaml
-resolver: lts-22.6
+resolver: lts-22.7
 packages:
 - text-2.0.2
 ghc-options:
@@ -122,11 +122,11 @@ packages in the `packages` list, rather than all packages in the snapshot.
 
 In order to specify Cabal flags for a package, you use the same syntax as the
 [flags](yaml_configuration.md#flags) key for build configuration. The
-following snapshot specification will be identical to `lts-22.6`, but
+following snapshot specification will be identical to `lts-22.7`, but
 it enables the `developer` Cabal flag:
 
 ~~~yaml
-resolver: lts-22.6
+resolver: lts-22.7
 packages:
 - text-2.0.2
 flags: