Add a flag to disable the hard requirement on the
build-tools-(depends) declared on the Cabal package.

When this flag is enabled (--ignore-build-tools), a build-tool which
can't be found does not block compilation.

Fixes #10061

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

API incompatible with our test suites

* 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>

This patch ensures that we correctly provision executables declared
in the build-tool-depends fields in all circumstances:

  - whether the build tool is external (from another package) or
    internal (declared in the current package)
  - whether the build tool is used at compile time (e.g. in a pre-build
    rule or in a Template Haskell splice) or at run time (e.g. when
    running a test-suite, benchmark or executable).

Note that correctly provisioning a build tool requires two pieces of
information:

  - making it available in PATH,
  - ensuring it has the correct environment variables overrides;
    in particular, the build tool needs to be able to find its own
    data directory.

The test case BuildToolPaths checks all of these situations are handled
correctly.

Matthew Pickering authored 1 year ago and Rodrigo Mesquita committed 11 months ago

This makes `withShorterPathForNewBuildStore` fit more nicely into the
rest of the testing infrastructure.

* Move `withShorterPathForNewBuildStore` to `TestM` monad
* Move responsibility for passing `--store-dir` to `cabalGArgs` function
* Move `findDependencyInStore` into `TestM`, and remove requirement to
  pass path to store directory.
* Introduce `testStoreDir` function which returns the store location
  (and honours `withShorterPathForNewBuildStore`)
* Migrate tests which use `withShorterPathForNewBuildStore`.

This commit introduces a new build-type, Hooks. A package using this
build type should provide a SetupHooks.hs module which exports
a value `setupHooks :: SetupHooks`. This is intended to replace the
Custom setup type. This allows Cabal to have finer-grained information
about the build, instead of having an opaque Setup executable to invoke.

Tests include:

  - error when returning an invalid component diff in a
    per-component pre-configure hook
  - error when declaring pre-build rules whose dependency
    graph contains cycles
  - error when we cannot find a dependency of a pre-build rule
  - warning when there are pre-build rules that are declared but
    never demanded
  - correctness tests for SetupHooks, e.g. that
    pre-build rules are run in dependency order (see the
    `SetupHooksRuleOrdering` test)

* Registered the NamedDefaults language extension

* Added changelog and Vim configuration lines

* Updated the expected hashes

---------

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

- Remove stm and containers from hackage-tests
- Remove tasty-expected-failure from check-tests
- Remove tasty-quickcheck from parser-tests
- Remove async, binary, Cabal-tests, deep-seq, integer-logarithms, rere, tagged and transformers from unit-tests

This commit makes the library functions in Cabal agnostic of the working
directory. In practice, this means that we distinguish `FilePath`s
from un-interpreted `SymbolicPath`s. The latter may be paths that are
relative to the working directory, and need to be interpreted with
respect to a passed-in argument specifying the working directory,
instead of using the working directory of the current process.
See Note [Symbolic paths] in Distribution.Utils.Path.

In particular, paths in the package description now use the SymbolicPath
abstraction, which allows specifying whether they are allowed to be
absolute, and, if they are relative, what they are relative to.
For example, source files are relative to a source search directory,
data files are relative to the data directory, and doc files are
relative to the package root.

Fixes #9702

As a warning (“Hackage would reject this package”), to prepare users
to GHC language editions.

- Satisfy -Wmissing-signatures in test-runtime-deps
- Satisfy -Wx-partial in HackageBenchmark
- Satisfy -Wunused-imports in QuickCheck.Instances.Cabal
- Use partial pattern for filtering in list comprehension
- Don't error on deprecated import

- Fix whitespace in cabal-testsuite + other tests

See: #4899

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

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

The aim of this commit is to modularise LocalBuildInfo to better
reflect implicit invariants.

The top-level split

  data LocalBuildInfo =
    NewLocalBuildInfo
      { localBuildDescr  :: LocalBuildDescr
      , localBuildConfig :: LocalBuildConfig
      }

reflects which part of a LocalBuildInfo are set in stone by Cabal
(the LocalBuildDescr), while LocalBuildConfig contains options that
can be controlled/modified by the user in some way.

The split

  data LocalBuildDescr =
    LocalBuildDescr
    { packageBuildDescr :: PackageBuildDescr
    , componentBuildDescr :: ComponentBuildDescr
    }

reflects that some parts of the information determined at configuration
time resides at the package level, while other pieces of information
are pertinent to individual components.

Finally the structure of LocalBuildConfig is aimed to reduce code
duplication between the Cabal library and cabal-install.

* Introduce `-i/--ignore` command-line option.
    e.g.  cabal check --ignore=missing-upper-bounds  will not display
    “Missing upper bounds” warnings.

* Additionally, a filterPackageChecksById function is now exported
  in Distribution.PackageDescription.Check.Warning; this can be
  used by third party tools.

* Add CheckExplanationIDString to `cabal check` messages.
    e.g. from
      Error: The 'license' field is missing or is NONE.
    to
      Error: [license-none] The 'license' field is missing or is NONE.

    This makes using the cabal check `--ignore` option more immediate.

* Spool `MissingField` into separate constructors.
  Introducing five new constructors for `CheckExplanation`
    MissingFieldCategory
    MissingFieldMaintainer
    MissingFieldSynopsis
    MissingFieldDescription
    MissingFieldSynOrDesc
  This provides better ergonomic for `cabal check --ignore` and makes
  it easier to update the manual if the need arises.

* Add tests for desiderable `--ignore` string qualities (not too long,
  without too many '-', unique).

* Warn when `--ignore` string is not recognised.
    Also add a test for this.

* Add documentation.

* Add changelog.

f-a authored 1 year ago and f-a committed 1 year ago

* Add a `Compat` module to accomodate two different `tar` interfaces.
* Tweak `-Wunused-packages` conditional (thanks Phil de Joux)

This commit re-designs the mechanism by which we make the .mix files of
libraries available to produce the Haskell Program Coverage report after
running testsuites.

The idea, for the Cabal library, is:

* Cabal builds libraries with -fhpc, and store the hpc artifacts in
  build </> `extraCompilationArtifacts`
* At Cabal install time, `extraCompilationArtifacts` is copied into the
  package database
* At Cabal configure time, we both
    - receive as --coverage-for flags unit-ids of library components
      from the same package (ultimately, when #9493 is resolved, we will
      receive unit ids of libraries in other packages in the same
      project too),
    - and, when configuring a whole package instead of just a testsuite
      component, we determine the unit-ids of libraries in the package
  these unit-ids are written into `configCoverageFor` in `ConfigFlags`
* At Cabal test time, for each library to cover (stored in
  `configCoverageFor`), we look in the package database for the hpc
  dirs, which we eventually pass along to the `hpc markup` call as
  `--hpcdir` flags

As for cabal-install:

* After a plan has been elaborated, we select the packages which can be
  covered and pass them to Cabal's ./Setup configure as
  --coverage-for=<unit-id> flags.
    - Notably, valid libraries are non-indefinite and
      non-instantiations, since HPC does not support backpack.
    - Furthermore, we only include libraries in the same package as the
      component being configured, despite possibly there being
      more library components in other packages of the same project.
      When #9493 is resolved, we could lift this restriction and pass
      all libraries local to the package as --coverage-for. See
      `determineCoverageFor` and `shouldCoverPkg` in Distribution.Client.ProjectPlanning.

Detail:
    We no longer pass the path to the testsuite's mix dirs to `hpc
    markup` because we only ever include modules in libraries, which
    means they were previously unused.

Fixes #6440 (internal libs coverage), #6397 (backpack breaks coverage),
doesn't yet fix #8609 (multi-package coverage report) which is tracked
in #9493, and fixes in a new way the previously fixed #4798, #5213.

* Add `cabal-version` 3.12

* Add test for #9331

- `cabal check`: Guard Paths_* behind `cabal-version: 3.12` or higher,
  “fail” and “succeed” tests.
- `cabal build`: Guard Paths_* behind `cabal-version: 3.12` or higher,
  “fail” test.

* Guard PackageInfo behind cabal-version ≥ 3.12

---------

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

Remove MIN_VERSION_base(4,7,0) as can't build anyway before ghc-8.4

It seems, GHC 9.8 changed something in the code generation for data types.
Structured class is supposed to catch such cases.

I noticed that Distribution.Utils.TempTestDir was only used in the
testsuite but defined in the Cabal library. Rather than expose this in
the public interface of the `Cabal` library, it is cleaner to refactor
it into a separate library (`Cabal-tests`) which can be used by any
testsuite component.

Also, in future it gives a clearer place to put utility functions which
need to be shared across the testsuite but not exposed in Cabal.
Cabal-tests can also freely add dependencies (such as exceptions) which
we might want to avoid adding to the Cabal library.

Fixes #9453

Previously, sparc64 was defined as an alias for the 32-bit SPARC
architecture which was true while SPARC mainland was mostly 32
bits. More recently, 64-bit SPARC has become a port of its own,
so it needs to be treated as a separate architecture.

* Fix Semigroup target instance

When two target names are the same, `mappend`ing them should not
error but just pick the first name.

* Add `desugarBuildToolSimple`

* Reimplement cabal check

* Reorder test output

* Fix autogen modules tests .cabal files

* Add a number of tests

* Add test for #7423

i.e. Do not warn on -O2 if under off-by-default package configuration
flag conditional.

* Add a regression for:

    * Add another -WErrr test
        This is to make sure we do *not* report it if it is under
        a user, off-by-default flag.
    * Add test for non manual user flags.
    * Add “absolute path in extra-lib-dirs” test
    * Add if/else test
    * Add “dircheck on abspath” check
    * Add Package version internal test
    * Add PackageVersionsStraddle test

* Add changelog for #8427

* Integrate various reviews

* Integrate Artem’s review

(review) Clarify `combineNames` documentation

By explaining the way it operates (working if the two names are equal
or one is empty) and renaming the function from `combineName` to
`combineNames`.

(review) Use guards instead of if/then/else

(review) Match inside argument list

(review) Replace “white” with “allow”

(review) Fix typo in comment

(review) Fix typo in Check module documentation

(review) Harmonise indentation for `data` decls

First field goes in a new line than the data constructor, so we
have more space.

(review) Rename `Prim` module to `Types`

(review) Add checkPackageFilesGPD

`checkPackageFiles` — which works on PD — was used to perform IO. We
introduce a function that does the same thing but works on GPD (which
is more principled).

`checkPackageFiles` cannot just be removed, since it is part of the
interface of Distribution.PackageDescription.Check. Deprecation can
be planned once “new check” is up and running.

* Integrate Andreas’ review

(review) Add named section to missing upper bound check

“miss upper bound” checks will now list target type and name (“On
executable 'myexe', these packages miss upper bounds”) for easier
fixing by the user.

(review) remove `cabal gen-bounds` suggestion

Reasonable as `cabal gen-bounds` is stricter than `cabal check`, see
https://github.com/haskell/cabal/pull/8427#issuecomment-1446712486


Once `gen-bounds` behaves in line with `check` we can readd the
suggestion.

(review) Do not warn on shared bounds

When a target which depends on an internal library shares some
dependencies with the latter, do not warn on upper bounds.

An example is clearer

    library
     build-depends: text < 5
    ⁝
     build-depends: myPackage,        ← no warning, internal
                    text,             ← no warning, shared bound
                    monadacme         ← warning!

* Integrate Artem’s review /II

(review) Split Check.hs

Check.hs has been split in multiple file, each une sub 1000 lines:

Check              857 lines
Check.Common       147 lines
Check.Conditional  204 lines
Check.Monad        352 lines
Check.Paths        387 lines
Check.Target       765 lines
Check.Warning      865 lines

Migration guide:
- Check              GPD/PD checks plus work-tree checks.
- Check.Common       common types and functions that are
                     *not* part of monadic checking setup.
- Check.Conditional  checks on CondTree and related matter
                     (variables, duplicate modules).
- Check.Monad        Backbone of the checks, monadic inter-
                     face and related functions.
- Check.Paths        Checks on files, directories, globs.
- Check.Target       Checks on realised targets (libraries,
                     executables, benchmarks, testsuites).
- Check.Warning      Datatypes and strings for warnings
                     and severities.

(review) remove useless section header

(review) Fix typo

(review) Add warnings documentation (list)

For each warning, we document constructor/brief description
in the manual.  This might not be much useful as not but it
will come handy when introducing `--ignore=WARN` and similar
flags.

* (review Andreas) Clarify CheckExplanation comment

Whoever modifies `CheckExplanation` data constructors needs to be
aware that the documentation in  doc/cabal-commands.rst  has to be
updated too.

* Move internal Check modules to `other-modules`

No need to expose Distribution.PackageDescription.Check.*
to the world. API for checking, for cabal-install and other
tools, should be in Distribution.PackageDescription.Check.

* Make fourmolu happy

Cabal codebase has now a formatter/style standard (see #8950).

“Ravioli ravioli, give me the formuoli”

* Do not check for OptO in scripts

See #8963 for reason and clarification requests.

* Remove useless PackageId parameter

It is now in the Reader part of CheckM monad.

* Do not check PVP on internal targets

Internal: testsuite, benchmark.
See #8361.

* Make hlint happy

* Fix #9122

When checking internal version ranges, we need to make sure we
are not mistaking a libraries with the same name but from different
packages. See #9132.

* Fix grammar

neither…nor, completing what done in #9162

* Integrate Brandon’s review: grammar

* Remove unnecessary `-fvia-C` check

Brandon’s review/II.

---------

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

* Add support for the 64-bit RISC-V architecture

* Update hashes in tests as instructed

* Fix changelog syntax

---------

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

Oleg Grenrus authored 1 year ago and f-a committed 1 year ago

This is affect of using indentOfAtLeast method:
any indentation greater than current offset is fine.

That behavior is desirable to parsing multiline field contents,
but it is a bit surprising for fields, which we expect to be aligned.

Such insonsistency seems to be always a mistake, and it's easy to fix once
a machine points it out.