Tell zlib not to use pkg-config (backport #9775)

(cherry picked from commit 62c74fe1)

* Fix changelog/readme

(cherry picked from commit ea0f4640)

* Remove previous release date

---------

Co-authored-by: Francesco Ariis <fa-ml@ariis.it>

Support GHC 9.12 (backport #9928)

(cherry picked from commit da6bdefd)

* Fix release notes grammar

See #9920.

* Fix whitespace

* Incorporate Brandon’s suggestions

See #9920.

* Incorporate Artem’s suggestions

See #9920.

* Do not repeat yourself

update zlib.cabal location (backport #9915)

The upstream zlib package was recently reorganized in a way that
caused our git fetch test to fail. Update it to match.

(cherry picked from commit 2ad9d63c)

* Update changelog for 3.12

(and for future WIP 3.12.1.0 cabal-install)

* Remove changelog.d files

GitLab CI: Shake up available platforms (backport #9865)

* Use `arch` explicitly in both jobs. I don't know why x86_64 is the
  default, and I don't like it.

* Stop using brew. This means a toolchain needs to already be installed
  where CI is run. This is the case today, although it's a bit fragile
  and I'll probably revisit it.

* Use a matrix build to clean up the yml.

* Use GHC 9.8.2 to work around GHC#24050

(cherry picked from commit 1f60a977)

(cherry picked from commit 50c0c0f8)

(cherry picked from commit 6b6c6842)

(cherry picked from commit 3792f658)

Redesign 'cabal path' command to account for projects (backport #9583)

* Redesign 'cabal path' command to account for projects

Previously, `cabal path` was only able to query from the global
configuration file, e.g., `~/.cabal/config` or the XDG equivalent.
Adding support for cabal project is a huge boost to usability.

We take the foundations and turn them into `cabal v2-path` which takes
project configuration, such as `cabal.project` into account.
Note, the command is still named `cabal path`, but for the sake of
disambiguation, we refer to this new iteration of the command as `cabal
v2-path`.

In addition, we add support for multiple output formats, such as
key-value pairs and json.

The key-value pair output prints a line for each queried key and its
respective value:

    key1: value2
    key2: value2

If only a single key is queried, we print only the
value, for example:

    value1

The json output format is versioned by the cabal-install version which
is part of the json object.
Thus, all result objects contain at least the key "cabal-install-version".

We expand the `cabal v2-path` to also produce information of the
compiler that is going to be used in a `cabal build` or `cabal repl` invocation.
To do that, we rebuild the install plan and query for the configured
compiler program.
This is helpful for downstream tools, such as HLS, to figure out the GHC
version required to compile a project with.

We also add an exhaustive test suite for 'cabal path' cmd

We test that each query honours cabal.project files, cli parameters, and
is composable with the other query flags.

We extend the test output normalisers for ghc compiler location and
cabal-install version, as the 'cabal path' command outputs the exact ghc
and ghc-pkg location. In addition, the json output format is versioned
on the cabal-install version.

Currently, we query the cabal-install version on each test normalisation
run. This might be unnecessary expensive, and could be avoided by
introducing a 'cabalProgram' that specifies how the program version can
be found. This way, we can cache the version query.

Add '--cache-home' flag thats shows the cabal's cache root

Rename '--cache-dir' to the more correct '--remote-repo-dir'.

* Update 'cabal path' documentation

* Add changelog.d entry

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 4a8a7c5d)

Update setupMinCabalVersionConstraint for GHC 9.10 (backport #9882)

(cherry picked from commit ecb174da)

Fix cabal install in the presence of extra-packages (backport #9719)

Support GHC2024 (fixes #9736) (backport #9791)

(cherry picked from commit 23a68409)

Fix `<more complex packages>` link lost in doc/cabal-package-description-file.rs (backport #9765)

(cherry picked from commit 05860310)

Show import tree provenance (backport #9578)

With this change to the solver message rendering, I also fix some bugs around project imports, adding tests for those cases. Reviewers asked that the Y-shaped import checks (using IORef) be made on a separate pull request. Removing those lead to cascading deletions.

- Regenerate expected .out files
- Show tree provenance of import constraint
- Add trimmed down PackageTests/VersionPriority
- Add changelog entry
- Use NonEmpty
- Fix check for cyclical import
- Use primes for next iteration
- Remove unused LANGUAGE pragmas
- Rename to projectConfigPathRoot
- Docs for ProjectConfigPath and showProjectConfigPath
- Renaming
- Add cyclical import tests with 1 and 2 hops in cycle
- Use full path for cyclical error message
- Expected output has project with full project path
- Add fullPath local function
- Project directory as FilePath, not Maybe FilePath
- Use (_, projectFileName) binding splitFileName
- Need full path to project parsing legacy
- Inline seenImports conversion
- Add cyclical checks with same file names and hops
- Add noncyclical tests that hop over folders
- Add a project testing skipping in and out of a folder
- Update expectations of cyclical tests
- Use canonicalizePath for collapsing .. when possible
- Capture trace for later
- Add module for ProjectConfigPath
- Move functions for ProjectConfigPath to its module
- Fetch URI is not prefixed with ./https://etc
- Document normaliseConfigPath
- Add doctests for normaliseConfigPath
- Add doctest of canonicalizeConfigPath
- Show an example of canonical paths
- Use importer and importee in canonicalizeConfigPaths
- Add logging

Extra-packages listed in a cabal project are to be fetched from hackage,
and will be in memory as 'NamedPackages' rather than resolved to
'SpecificSourcePackage'.

On install, we need to make source-dists for all the specific source
packages, and fetch other packages from hackage. Since extra-packages
are already 'NamedPackages', we simply return them along the sdistize-d
specific source packages and the hackage source packages -- they will be
correctly fetched from Hackage from install.

Previously, cabal install <tgt> on a project with extra-packages would
fail because the branch of 'NamedPackage' for 'PackageSpecifier' was
simply unimplemented.

Fixes #8848

(cherry picked from commit c671f0e9)

Conform BSD-2-Clause and BSD-3-Clause text to SPDX (backport #9813)

`cabal init` text for BSD-2-Clause and BSD-3-Clause licence differed
slightly from the one published at SPDX. [1] [2]

This caused some problems to users when dealing with licence-recognition
software. [3]

[1] https://spdx.org/licenses/BSD-2-Clause.html
[2] https://spdx.org/licenses/BSD-3-Clause.html
[3] https://discourse.haskell.org/t/non-standard-license-generated-by-stack-new/9059

(cherry picked from commit 1e86730a)

Bump time upper bound to acccomodate 1.14 (backport #9848)

(cherry picked from commit e7d9b84a)

CI validate-old-ghcs: pin to haskell-actions/setup@v2.6 (backport #9859)

This provides temporary life support to the `validate-old-ghcs` action
until node16 will be finally axed by GHA in May 2024.

Workaround for:
- https://github.com/haskell/cabal/issues/9858

(cherry picked from commit 2da8b2fa)

* Bump version numbers for 3.12.0.0

Version fields, constraints, licences, and bootstrap.

☞ N.B.:
- This commit removes 8.10.7 from bootstrap list.
- This release only deals with Cabal, not cabal-install.

* Update index state in cabal.project.release

This is needed since we need the new (0.6.2.5) release of
hackage-security.

* Regenerate bootstrap .json files

Update licence list

Per https://github.com/haskell/cabal/wiki/Updating-the-license-list
to version 3.23 (2024-02-08) of SPDX License List.

Make `check` recognise `main-is` in conditional branches (backport #9768)

* Add tests for #9742

`main-is` not picked up when inside a multibranch CondNode.

* Fix comments

* Add simplifyBranch to Distribution.Types.CondTree

Goes hand in hand with with simplifyCondTree.

* Make `check` deal correctly with multiple branches

`cabal check` had a problem recognising fields in presence of
multiple branches. This patch fixes the problem and does not
meaningfully increases CI time of particularly taxing tests
(like “duplicate flagged dependencies” from MemoryUsage).

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
(cherry picked from commit 74b1f215)