Add Issue/PR contributing guidelines

Regarding issues/PRs relationship.

Use in-tree Cabal library for `cabal-install` tests with custom setup.

The idea here is to pass a `--package-db` flag to `cabal-install` which
contains just `Cabal` and `Cabal-syntax` of the specific version. This
allows `cabal-install` tests to use the in-tree `Cabal` version,
something which you can easily run into and get very confused about when
writing tests.

There are a few options which can be passed to `cabal-tests` executable
to control which Cabal library you will test against.

1. --boot-cabal-lib specifies to use the Cabal library bundled with the
   test compiler, this is the default and existing behaviour of the
   testsuite.
2. --intree-cabal-lib=<root_dir> specifies to use Cabal and Cabal-syntax
   from a specific directory, and `--test-tmp` indicates where to put
   the package database they are built with.
3. --specific-cabal-lib=<VERSION> specifies to use a specific Cabal
   version from hackage (ie 3.10.2.0) and installs the package database
   into --test-tmp=<DIR>

The end result is that changes in the Cabal library can be tested with
cabal-install tests in the testsuite.

There have been a number of confusing issues with people writing tests
for changes in the Cabal library which never ran because of
cabal-install tests always used the boot Cabal library (see #9425
for one).

Fixes #9681

update copyright for 2024

testsuite: Run tests in temporary system directories

1. Working directory is not contaminated with results of the testsuite.
   Tests can be written in a more liberal way (creating/writing files
   etc).
2. The tests are more hermetic.. for example it was basically impossible
   to write a test which run outside of a project context.
3. The overall path lengths will be much shorter, which has been a
   consistent issue on windows. We can remove hacks like
   `withShorterPathForNewBuildStore`.

Fixes #9711

Download stackage.org/.../cabal.config locally

cabal-install: Clarify the semantics of package-db flag

In this PR we make the `--package-db` flag apply only to the default
immutable initial package stack rather than also applying to the store
package database.

There are two special package databases which cabal install knows about
and treats specially.

* The store directory, a global cache of installed packages where cabal
  builds and installs packages into.
* The inplace directory, a local build folder for packages, where cabal
  builds local packages in.

It is very important that cabal registers packages it builds into one of
these two locations as there are many assumptions that packages will end
up here.

With the current design of the `--package-db` flag, you are apparently
allowed to override the store location which should have the effect of
making the last package database in the package stack the "store"
directory. Perhaps this works out in theory but practically this
behaviour was broken and things were always registered into the store
directory that cabal knew about. (The assertion in
`ProjectBuilding.UnpackedPackage` was failing (see added test)).

With `--package-db` not being able to modify the location of the store
directory then the interaction of `--package-db`, `--store-dir` and
`--dist-dir` flags become easy to understand.

* `--package-db` modify the initial package database stack, these
  package database will not be mutated by cabal and provide the initial
  package environment which is used by cabal.
* `--store-dir` modify the location of the store directory
* `--dist-dir` modify the location of the dist directory (and hence
  inplace package database)

Treating the flags in this way also fix an assertion failure when
building packages.

Fixes #9678

CI updates (drop 8.4.4, update old-ghcs, update bootstrap plans)

It fails in the old-ghcs 8.4.4 configuration, and debugging why seems to
have very little pay-off for this niche feature in a very old
configuration.

And add the relevant CI jobs for these plans

We were missing coverage from running tests with these ghc versions.

We no longer support 8.4.4 as it is older than three years.
cabal-install can
still be used with 8.4.4, but just not built with it, and this is tested
by the old-ghcs jobs.

add the extension ListTuplePuns (GHC proposal 475)

Fix #9534 Add constructor `PPC64LE` to type `Arch`, for powerpc64le

Also makes consequent changes.

Fix multi-repl closure computation with invalid Custom setup

This patch deletes a lot of hairy logic to do with removing "bad" edges
from the closure. Now the solver just forces `Cabal >= 3.11` universally
when `--enable-multi-repl` is enabled.

Fixes #9710

Modularise writeAutogenFiles

This commit modularises the logic for generation of autogenerated files
and autogenerated modules.

This commit adds a Suffix newtype to describe suffixes as handled
by suffix handlers & preprocessors, and changes the PPSuffixHandler
type definition to use it.

It also moves some type definitions from Distribution.Simple.PreProcess
to the new module Distribution.Simple.PreProcess.Types.

As this commit changes the definition of PPSuffixHandler, it will
break custom Setup scripts which use the 'hookedPreProcessors'
functionality.

Add test cabal install remote-pkg for #9697

In #9697 we fixed passing local options to cabal install targets, but
rebasing accidentally dropped one of the added the tests for that PR,
which tested cabal install <target>, where <target> was only available
from a remote repository.

cabal-install: justify why legacy-fallback is used

This commit makes it so that cabal-install can explain the reason why
it used the legacy fallback, instead of building per-component.

Refactor CmdInstall / fix bug in #9697

CmdInstall.installAction is ~300 lines long and full of nested scopes
and ad-hoc logic. This change hopes to make it more readable and
understandable.

- Lift withProject and withoutProject out of installAction and split
  their relative concerns. E.g. not parsing URIs is installAction's
  concern not withProject's (which would just return a constant []).
- Split an intermediate step into a separate function, resolveTargetSelectorsInProjectBaseContext.
- Reuse withGlobalConfig and specFromPkgId (renamed from pidPackageSpecifiers).
- Avoid trying withProject a second time in case no target is specified.
- Fix a bug introduced in 802a326f where
  establishProjectBaseContext is called in a non-project setting. Also
  simplify its original implementation by moving the change into
  withProject rather than calling establishProjectBaseContext a second
  time.
- Document the interaction between cabal v2-install and local configuration
  and add few comments.

Merge two Globbing Modules and Fix #5349

We use the datatype representation from the globbing in cabal-install,
but preserve a standalone parser for globs present in cabal files, whose
specification is constrained by the cabal specification. The
implementations are merged taking the best parts of each.

We also make sure sdist is robust to accidentally-listed directories,
as the refactor of the globbing modules re-uncovered this issue, and
required a prompt fix for the refactor not to break some things.

Fixes #5349

* Add -Wunused-packages to the packages

Cabal, Cabal-syntax, cabal-install, cabal-install-solver

* Remove unused text dependency

* remove unguarded warning

* Remove 8.10 condition for unused-packages

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

* Generate changelogs

Co-authored-by: Hécate Moonlight <Kleidukos@users.noreply.github.com>

Allow zlib-0.7