Some git files are marked as read-only. To ensure we delete the folders we are
supposed to, we first remove the read-only attribute via `CMD.exe`, then we
forcibly delete the relevant directory.

* Improve bat scripts for CCompilerOverride

* Ensure Windows tests can cleanup the temp directory

* Implement `flaky` combinator

* Remove outdated tests

* Remove broken tests

These tests were testing for messages that were removed with the `cabal check` rework.

* Make `skip` and `broken` messages uniform

* Mark flaky tests

* Re-enable DeterministicTrivial

* Fix MacOS canonical paths

* Extend cabal-testsuite readme with `flaky`

* Skip non-terminating tests in Windows CI

---------

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

Disallowing whitespace while parsing target selectors incorrectly
disallows file targets with whitespace in the paths, which can issues
when users pass absolute paths.

fixes #8875

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

- Fix whitespace in cabal-testsuite + other tests

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

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

Hannes Siebenhandl authored 1 year ago and Mikolaj Konarski committed 1 year ago

This reverts commit 3f4c81fd.

This change removes support for building sub-component targets in
cabal-install, since no versions of Cabal support this feature.

The test RunMainBad is also dropped because without the concept of a
file target, RunMainBad is the same test as ScriptBad.

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

Matthew Pickering authored 2 years ago and Ben Gamari committed 1 year ago

* The top-level user interface to enable the use of the semaphore is the
  `--semaphore` flag. If you pass `-j4 --semaphore` then cabal will
  create a semaphore with 4 slots which is passed to ghc using the
  `-jsem` option so that all GHC processes coordinate to use 4
  capabilities.

  - The semaphore logic is provided by a new package `semaphore-compat`
    which provides a cross-platform abstraction for semaphores.

* The low level `./Setup.hs build` interface accepts the `--semaphore
  <SEMAPHORE>` option, which can be used to directly pass the semaphore
  you require to the Setup script.

Also adds ellipsis to lines in *.out files.

Matthew Pickering authored 2 years ago and Francesco Gazzetta committed 1 year ago

There are several parts to this patch which are logically distinct but
work together to support the overal goal of starting a GHCi session with
multiple packages loaded at once.

1. When a user writes "cabal repl <target>" then if the user is using a
   compiler > ghc-9.4.* then we will attempt to start a multi-session
   which loads the selected targets into one multi-package session of
   GHC.
1a. The closure property states that in order to load components `p` and `q` into
    the same session that if `p` depends on `z` and `z` depends on `q`
    then `z` must also be loaded into the session.
1b. Only inplace packages are able to be loaded into a multi session (if a component
    `z` exists then it is already made into an inplace package by
    cabal). Therefore cabal has already engineered that there is source
    code locally available for all packages which we will want to load
    into a session.

2. The solver is unmodified, the solver is given the repl targets and
   creates a build plan as before. After the solver is completed then in
   `setRootTargets` and `pruneInstallPlan` we modify the install plan to
   enforce the closure property and mark which dependencies need to be
   promised.

   * Mark the current components as `BuildInPlaceOnly InMemory`, which
     indicates to the compiler that it is to be built in a GHC
     multi-session.
   * Augment the component repl targets to indicate that components
     required by the closure property (in addition to normal targets)
     will be loaded into the repl.
   * Modify the dependency edges in `compLibDependencies` to indicate
     which dependencies are the promised ones (which is precisely
     components which are `BuildInPlaceOnly InMemory` build styles).
     This is the field which is eventually used to populate the
     `--dependency` argument to `./Setup configure`.

Fixes #8491

* Use shorter hash for script-builds directories

Using a Base64 hash and truncating it to 26 characters, saves 38 chars,
which helps avoid long paths issues on Windows, while still providing
130 bits of hash in order to avoid collisions.

Bug #8841

* Use the script cache dir as the dist dir

Putting script build products under dist-newstyle within the cache
directory is unnecessary because we already control the cache directory
and can ensure there are no conflicts.

* Use the actual script name in the executable name

Previously, the script name was sanitized in final executable name,
because the executable name had to match the component name, which only
allowed for a limited character set. Now we can use the actual script
name in the executable name. This only lets us shorten the component
name without losing clarity.

* Add changelog entry

* Reenable script tests for Windows/ghc-9.4.*

Partially revert 78cbeba1.

* do not print "up to date" unless running build

* Update cabal-tests

* Add changelog

* Remove accidentally added test generated files

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

We've seen some instability in the test, compare

  https://github.com/haskell/cabal/issues/8416

This adds timestamped output to make it easier to
see what goes wrong in case the test fails again.

This makes the `finally` apply to the last `do` block as intended.
No real effect on the test, though.

* Turn off T3827 for new GHCs due to heisenbugs not caused by cabal

* Disable the test totally on Linux until we stop taking GHC from GHA

See https://github.com/haskell/cabal/issues/8032#issuecomment-1204113187

* It failed on OSX now, so let's disable it everywhere except on Windows

Who would have thought.