* Changelogs for 3.12.1.0 (#10124)

* changelog for 3.12.1.0

* fixup! changelog for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>

* fixup! changelog for 3.12.1.0

* fixup! changelog for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

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

* fixup! Changelogs for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

* fixup! Changelogs for 3.12.1.0

---------

Co-authored-by: Artem Pelenitsyn <a.pelenitsyn@gmail.com>
Co-authored-by: ffaf1 <fa-ml@ariis.it>
(cherry picked from commit 2067ed19)

# Conflicts:
#	release-notes/Cabal-3.12.0.0.md

* fixup! Changelogs for 3.12.1.0 (backport #10124)

---------

Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

Add support for building profiled dynamic way

New options for cabal.project and ./Setup interface:

* `profiling-shared`: Enable building profiling dynamic way
* Passing `--enable-profiling` and `--enable-executable-dynamic` builds
  profiled dynamic executables.

Support for using `profiling-shared` is guarded behind a constraint
which ensures you are using `Cabal >= 3.13`.

In the cabal file:

* `ghc-prof-shared-options`, for passing options when building in
  profiling dynamic way

Other miscellenious fixes and improvements

* Some refactoring around ways so that which
  ways we should build for a library, foreign library and executable is
  computed by the `buildWays` function (rather than ad-hoc in three
  different places).

* Improved logic for detecting whether a compiler supports compiling
  a specific way. See functions `profilingVanillaSupported`,
  `dynamicSupported`, `profilingDynamicSupported` etc
  These functions report accurate infomation after ghc-9.10.1.

* Fixed logic for determining whether to build shared libraries. (see
  #10050)
  Now, if you explicitly enable `--*-shared`, then that will always take
  effect. If it's not specified then `--enable-executable-dynamic` will
  turn on shared libraries IF `--enable-profiling` is not enabled.

* Remove assumption that dynamically linked compilers can build dynamic
  libraries (they might be cross compilers.

* Query the build compiler to determine which library way is necessary
  to be built for TH support to work.
  (rather than assume all compilers are dynamically linked)

* An extensive test which checks how options for `./Setup` and
  `cabal-install` are translated into build ways.

Fixes #4816, #10049, #10050

* Disable arch-native flag when building releases that we distribute

* Use the constraints stanza

* Also disable the flag in cabal.validate.project

Skip tasty-quickcheck 0.11

API incompatible with our test suites

Depend on tar-0.6.3.0

Using the updated version of this library improves performance of
cabal-install so it's worthwhile to make sure the bootstrap plans use
this version.

tar-0.6.3.0 has much improved performance of deserialising .tar index
which has significant ramifications for the start-up time of
cabal-install.

See #10110

perf: Group together packages by repo when verifying tarballs

verifyFetchedTarball has the effect of deserialising the index tarball
(see call to Sec.withIndex).

verifyFetchedTarball is called individually for each package in the
build plan (see ProjectPlanning.hs). Not once per repo.

The hackage tarball is now 880mb so it takes a non significant amount of
time to deserialise this (much better after haskell/tar#95).

This code path is important as it can add 1s with these 38 calls on to
the initial load of a project and scales linearly with the size of your
build tree.

Reproducer: Simple project with "lens" dependency deserialises the index tarball 38 times.

Solution: Refactor verifyFetchedTarball to run once per repo rather than once per package.

In future it would be much better to refactor this function so that the
items are not immediately grouped and ungrouped but I didn't want to
take that on immediately.

Fixes #10110

* Add MHS as a recognized compiler.

* Add Changelog entry

* Add comment.

* Update checksums.

* Update more checksums.

---------

Co-authored-by: Lennart Augustsson <lennart.augustsson@epicgames.com>

Be more careful in handling unconfigured programs in the program database

There was some hacky logic in place to give a "haskell-suite" compiler
a dummy location so that we would attempt to configure it.

This logic is no longer necessary since 'configureRequiredProgram' was
changed to accomodate the situation in which 'lookupKnownProgram' fails.
In fact, it is downright harmful, as this dummy location will trigger
errors when we attempt to configure all known programs, which is
a necessary step before attempting to serialise a program database.

This commit configures the unconfigured programs in the program database
when we are building a custom Setup script. This ensures that we can
find the "strip" program which might otherwise still be unconfigured.

In configureRequiredProgram, we would unconditionally configure the
program, even if it was configured already. To explain why this is
problematic:

  - The programs we try to configure in this function are those that
    arise from a "build-tool-depends" field of a package.
  - If the program is not in the "unconfigured" state, we would
    unconditionally treat it as a simpleProgram.
    This means that if such a program is builtin but is not a
    simpleProgram, we might fail to configure it properly.

This problem arises when we configure programs more eagerly: when, in
the past, we might have gone looking up an unconfigured program and
successfully configured it, now we might find the program is already
configured.

One example in which this would cause an issue is when we have

   build-tool-depends: hsc2hs

If we end up re-configuring hsc2hs in configureRequiredProgram, we would
treat it as a simple program, which would cause us to be unable to
determine its version.

We should configure unconfigured programs before serialising them
(using the Binary ProgramDb instance) in
Distribution.Client.ProjectPlanning.configureCompiler, as otherwise
we can accidentally discard information.

This isn't currently a live bug, because in practice we end up
re-running configuration steps when interfacing with the Cabal library.
However, in the bright future in which we avoid re-configuring things
when building a Cabal package that we already determined when invoking
cabal-install, this starts causing problems.

Change packages default to empty

testsuite: Pass pkgdb of store used for intree Cabal

Fix recomp bug by invalidating cache on build exception

Be sure to invalidate the cache if building throws an exception!
If not, we'll abort execution with a stale recompilation cache.
See ghc#24926 for an example of how this can go wrong.

Use SetupHooks for Configure build-type

This commit implements the Configure build-type in terms of Hooks,
when build-type: Hooks is available (for Cabal >= 3.13).

This moves Configure away from an implementation in terms of UserHooks,
i.e. away from the Custom build-type.

Issue #10063 points out that cabal exits before the external command
has finished executing. This was a simple oversight to not
waitForProcess on the result of calling createProcess.

This also points out the flaw that there isn't a way for external
commands to signal failure, so we now also propagate the exit code from
the external process.

Fixes #10063

update requests per CVE-2024-35195

GHC 9.10 ships with a new wired-in package, ghc-internal, which cannot
be reinstalled. This commit prevents cabal-install from attempting it.

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

* add the applicable new (versions 9.2 - 9.10) GHC flags to normaliseGhcArgs

Actionable flags are:
- fdiagnostics-as-json (changes the format GHC outputs its diagnostics)
- fprint-error-index-lists (changes the way GHC displays compile time)
- fbreak-points (enables/disables break-points in GHCi)
- dipe-stats (dumps information about which info tables have IPE
  information)
- ffamily-application-cache (only changes the speed of the compiler)
- fprint-redundant-promotion-ticks
- show-error-context
- unoptimized-core-for-interpreter (only applies to GHCi)

* [chore] correct the flag names and add a FUTUREWORK

Bump dependencies and cabal-version

For `Cabal` and `cabal-install`.

base and QuickCheck.

Fix --program-suffix resulting in invalid symlink

Currently the options `--program-{prefix,suffix}` for cabal install
affects the name of the file in the install directory *and* the
executable name in the store. The installation fails:

- If using `--install-method=symlink`, the *target* of the symlink is
  not affected by the affix options and it results in an invalid symlink.
- If using `--install-method=copy`, the copy fails because the source
  is not found.

Another issue is that it affects the computation of the hash of the
build directory in the store, resulting in needless rebuild when using
successively different affix options.

Fixed by making the name of the executable in the store canonical, i.e.
always ignoring the program affix options.

Added a test for all the combinations of `--install-method` and program
affixes options.

Two fixes to multi repl command