This reverts commit 8bdda9c0.

In configureCompiler the call to configureAllKnownPrograms was too
eager. When called it selected the version of tools from PATH (such as
alex), and then when a package was configured these tools were passed
using `--with-alex` options to configure, which meant that the
build-tool-depends versions were not used. (See #10692)

Why was this call introduced in the first place? Because
configureCompiler would a different result depending on whether:

* It is run for the first time, the `ProgramDb` will contain
  unconfigured programs.
* It is run subsequently, `ProgramDb` is read from disk, it does not
  contain unconfigured programs.

Reverting this commit rexposes the bug that the serialised ProgramDb
will not contain UnconfiguredPrograms (in the case where reconfiguring
is avoided).

However, there are no code paths which require this logic in
`cabal-install` currently. The configuration phase happens again each
time that `Cabal` is called, with a populated `ProgramDb`. We will
fix this before the next major `cabal-install` release, but it would not
be suitable to backport.

In the future we will fix this properly by refactoring
`configureCompiler` so that `ProgramDb` is not serialised. The general
approach will be to make `configCompilerEx` return a pair of configured
programs (`ghc` and `ghc-pkg`) and expose an additional function from
`Cabal` which uses these two programs to perform the modifications to
the `ProgramDb` which `configCompilerEx` performs.

Also see #2238 and #9840

Fixes #10692

Add source file to project parse errors and warnings

- Track which file has errors and which has warnings
- Add test for import parse warnings
- Remove added type sigs, use e for error type
- Move ProjectParseResult into its own module
- Import qualified from Deprecated.ParseUtils
- Reverse warnings so they are in line number order
- Report parse result error in imported config
- Split project test into warning and error tests
- Add type synonyms for project parse
- Extract function reportProjectParseWarnings
- Show the snippet that doesn't parse
- Add if, elif and else test projects
- Fix else for elif typo
- Show provenance if not root
- Rerun expected output with provenance
- Redo ParseWarningProvenence with ordered output
- Add ProjectParseError record
- Reword badly formed comment lines
- Satisfy fix-whitespace
- Add changelog entry
- Updated - indented expectation
- No snippet when modifying compiler under condition
- Only show custom message with snippet
- Rerun expected output with source
- Use a Doc for the ReportParseResult message
- Update expected .out files
- Use normalized path when recursing
- Consistent projectParse ... source
- Consistent projectParse ... normSource
- Use normalizeWindowsOutput
- Use .md extension on changelog entry
- Satisfy HLint
- Revert elif to else, see that this is wrong and undo

cabal-install 3.14.1.1 release notes

Add `make style-todo` and fourmolu on off comments

Only munge internal dependencies when printing when there is no explicit syntax

* In `postProcessInternalDeps` the shadowing logic which existed prior
  to cabal format 3.4 is implemented in a post processing step.

  The algorithm there replaces any references to internal sublibraries
  with an explicit qualifier. For example if you write..

  ```
  library
    build-depends: foo

  library foo
    ...
  ```

  this is reinterpreted as

  ```
  library
    build-depends: mylib:foo

  library foo
    ...
  ```

* In `preProcessInternalDeps` the inverse transformation takes place,
  the goal is to replace `mylib:foo` with just `foo`.

* Things go wrong if you are using version 3.0 for your cabal file
  because
  - In 3.0 the qualifier syntax is introduced so you can be expliciit
    about sublibrary dependencies
  - The shadowing semantics of non-qualified dependencies still exists.

  So the situation is that the user is explicit about the sublibrary

  ```
  library

  library qux
    build-depends: mylib:{mylib, foo}

  library foo
  ```

  1. Post-process leaves this alone, the user is already explicit about
     depending on a sublibrary.
  2. Pre-processing then rewrites `mylib:{mylib, foo}` into two
     dependencies, `mylib` and `foo` (no qualifier).
  3. When parsed these are two separate dependencies rather than treated
     as one dependency, roundtrip test fails.

Solution: Only perform the reverse transformation when the cabal library
version is <= 3.0 and doesn't support the explicit syntax.

Now what happens in these two situations:

1. ```
   library
     build-depends: foo

   library foo
     ...
   ```

  this is reinterpreted as

  ```
  library
    build-depends: mylib:foo

  library foo
    ...
  ```

  then printed and parsed exactly the same way.

2. Explicit syntax is parsed and printed without being munged (when
   supported)

Note: Mixins only supported sublibrary qualifiers from 3.4 whilst
dependencies supported this from 3.0, hence the lack of guard on the
mixins case.

Fixes #10283

make formatting of `build-depends` consistent

https://github.com/haskell/cabal/pull/10714/commits/7d791b9da10b5034e7a997a0044ded5575fe123f

`*.cabal` files in this project presently have a mix of formatting of `build-depends`.
Make them all consistent with:
https://cabal.readthedocs.io/en/3.4/cabal-package.html

No changes to any dependencies.

Add a cabal target command

Fix file+noindex URI usage on Windows

Fix #9507 Describe accurately acceptable package names

Also extinguishes false positive in typo detection.

Also aims to make corresponding changes to buildinfo-reference-generator, including the `Cabal-described` package. Adds `alphanumNotDigit` and now specifies `alphanum` by inserting digits into `alphanumNotDigit`.

The description of `alpha-num-not-digit` is added to the introduction to the section on 'Non-terminals' to accommodate the limitation of buildinfo-reference-generator that only a single 'formula' can follow a single paragraph of narrative for each non-terminal production.

cabal-install.cabal: bump upper bound for random

Add support for Windows Aarch64

Co-authored-by: Cheng Shao <terrorjack@type.dance>

- Avoid list in the help
- Use establishProjectBaseContext
- Remove withContextAndSelectors
- Use rebuildInstallPlan and resolveTargets
- Extract targetForms
- Satisfy hlint
- Remove unnecessary do
- Use safeHead
- Call printPlanTargetForms for everything
- Remove planTargetForms
- Rework command description
- Remove script as a possible TARGET form
- Section help into; intro, targetFroms and ctypes
- Use pretty printing for examples
- Short form and long form
- Add a changelog entry
- Need nixStyleOptions for cabal-testsuite
  - unrecognized 'v2-target' option `-vverbose +markoutput +nowrap'
  - unrecognized 'v2-target' option `--builddir'
  - unrecognized 'v2-target' option `-j1'
- Use notice so target forms are marked output
- Add tests of target all, implicit and explicit
- Add tests of all:exes and all:tests
- Add test of all:benches
- Add tests with --enable-tests and --enable-benchmarks
- Warn that package targets display libs and exes
- Add package target tests
- Add path target tests
- Add component target tests
- Add c package with only a library
- Add tests for missing ctypes
- Exclude new-target from other commands
- Move target command to configuration group
- Add target command docs
- Add cabal target docs
- A significant change
- Drop cleans from tests
- Use noticeDoc to preserve indent
- Satisfy fourmolu
- Show the number of matches found matching query
- Change synopsis of command, target verb
- Remove disclosed, use show, WARN and NOTE
- Typo command singular
- Bring the command docs inline with --help docs
- Remove disclosing from changelog
- Only by default, not *only*.

Co-Authored-By: brandon s allbery kf8nh <allbery.b@gmail.com>

Remove unused -XCPP

Fix file+noindex URI usage on Windows

Cabal: Honour -working-dir flag when running test executables

A simple fix to run the test executable in the `-working-dir`.

Fixes #10704

Suppress ghc-pkg warnings emitted when an empty packages is being registered

When a package contains a library that has no modules, "./Setup register"
tries to register the library with fields "haddock-interfaces:" and
"haddock-html:" pointing at non-existent files or directories, and "ghc-pkg
register" warns about them.

To suppress the warnings prevent these fields from being generated when
there are no modules.

Ignore haddocks