Matthew Pickering authored 3 months ago and Mikolaj Konarski committed 1 month ago

This commit updates the outdated command to the new v2 architecture:

- Transform the old `outdated` command into a new v2-style command `v2-outdated`
- Support three modes of operation:
  - Check for outdated dependencies in v1-style freeze file
  - Check for outdated dependencies in project context (cabal.project & cabal.project.freeze)
  - Check for outdated dependencies in local packages

Since the `cabal outdated` command now supports the v2-architecture, you
can request to run the `v2-outdated` command on any target.

I also introduced the `resolveTargetsFromLocalPackages` which resolves
which local packages targets refer to without having to run the solver.
This will be useful for `cabal check` as well.

A change in behaviour from before is that the package description is
flattened, so all bounds will be warned about rather than those in
conditional branches being ignored.

Fixes #8283

Matthew Pickering authored 1 month ago and Mikolaj Konarski committed 1 month ago

This commit refactors `resolveTargets` to allow you to either resolve
targets from

* The output of the solver by `resolveTargetsFromSolver`
* The package descriptions `resolveTargetsFromLocalPackages`

This allows you to use `v2-` infrastructure with commands which don't
require running the solver step (for example, v2-outdated).

plan.json: Include compiler-abi field

The plan.json file was missing crucial information needed to locate
packages in the store directory structure. When cabal-install stores
packages, it uses a full compiler identifier including an ABI tag (e.g.,
"ghc-9.10.1-69c3") but plan.json only included the basic compiler ID
("ghc-9.10.1"). This made it impossible for external tools like
cabal-plan to correctly locate packages and their files in the store.

This commit adds a new "compiler-abi" field with the ABI tag string

The issue reported in the original ticket seems to be about the location
of LICENSE files, but the plan.json may still lack sufficient
information to locate all license files since the packages may not be
located in the store, but in different package databases given by
the --package-db flag.  This will do for now.

Fixes #10726

multi-repl: Support module renaming for ghc-9.12 onwards

Matthew Pickering authored 3 months ago and Mikolaj Konarski committed 1 month ago

In ghc-9.12 the -rexported-module flag was extended to add support for
module renaming.

Therefore now if a module uses a module renaming, then the
-reexported-module flag is passed the renaming.

Fixes #10181

Implement v2-gen-bounds function

Matthew Pickering authored 4 months ago and Mikolaj Konarski committed 1 month ago

This commit implements project-aware functionality for the `cabal gen-bounds` command,
allowing it to work correctly in multi-package projects. Previously, running `gen-bounds`
from within a package directory that depends on another local package would fail
because it couldn't find the local dependency.

The implementation follows the same pattern as other v2 commands, creating a full
project context that knows about all packages defined in the cabal.project file.
This allows `gen-bounds` to properly analyze dependencies between local packages
and suggest appropriate bounds.

```
cabal gen-bounds <TARGET>
```

Fixes #7504 #8654 #9752 #5932

Clarify role of ~/.cabal when determining config file.

Athas authored 1 month ago and Artem Pelenitsyn committed 1 month ago

This is purely a documentation change that makes the behaviour more explicit.

The actual behaviour is unchanged, although the need for a five step checklist
to find the config file suggests that perhaps things have gotten a bit out of
hand.

* ci(mergify): upgrade configuration to current format

* patch up auto-upgrade brokenness

yet again

---------

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

test suite: mark DedupUsingConfigFromSimple as flaky

see https://github.com/haskell/cabal/issues/10975

Fix PATH changes not triggering REPL reconfiguration (#2015)

Matthew Pickering authored 4 months ago and Mikolaj Konarski committed 2 months ago

When a user's PATH environment variable changes between Cabal commands,
the environment in the REPL becomes incorrect. This occurs because
during initial package configuration, the current PATH is captured via
`programSearchPathAsPATHVar` and then stored in the `programOverrideEnv`
field of a ConfiguredProgram. These `ConfiguredProgram`s are subsequently
serialized into the setup-config file, effectively baking in the PATH
environment from the time of configuration.

The issue manifests when `PATH` is updated after initial configuration.
Although the solver re-runs when detecting `PATH` changes, the
`dryRunLocalPkg` function examines `ElaboratedConfiguredPackage` and
incorrectly determines that nothing has changed that would require
reconfiguration. This decision is incorrect because `setup-config` now
contains a stale reference to the original `PATH` value, which no longer
matches the current environment.

To fix this problem, we need to store the `ConfiguredProgram`s directly in
`ElaboratedConfiguredPackage`. This approach will ensure that when `PATH`
changes, the `ConfiguredProgram`s will also change, properly triggering
reconfiguration. While this solution will cause more recompilations when
`PATH` changes, it guarantees that the correct environment is always used
during builds and REPL sessions.

An alternative approach would be to stop baking the `PATH` variable into
the environment of programs, but this would require more substantial
changes to how Cabal manages environment variables.

Fixes #2015

Adding JavaScript Preprocessor Support

Add JSPOptions tests

Add regressions tests

Co-authored-by: Mateusz Goslinowski <mateusz.goslinowski@gmail.com>

If ghc-options is not passed when compiling js, Cmm or asm, that's a bug

add GhcOptions test

partial fix for #10721

cabal-install.cabal: allow open-browser-0.4

Make `Flag a` a type synonym for `Last (Maybe a)`

Bodigrim authored 2 months ago and Mikolaj Konarski committed 2 months ago

As http://www.haskell.org/pipermail/cabal-devel/2007-December/001509.html
explains, `Data.Monoid.Last` was introduced only in base-3.0 and was too
new in 2007 to rely on. Thus a compatibility shim `data Flag a` was
vendored in.

We are long past 2007 and `Data.Monoid.Last` can now be used instead.
The commit keeps providing `Flag` and `NoFlag` as pattern synonyms
for backward compatibility, but makes `type Flag = Last.`

* ci(mergify): upgrade configuration to current format

* fixup! ci(mergify): upgrade configuration to current format

---------

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

Mark untrimmed import test as flaky

Add Haddock documentation to Cabal's autogen modules

Implement assert matches with assert on

* Clarify splitting/passing behaviour for --*-option(s) arguments

* Further clarify precise quote parsing behaviour of --*-options options

* Use OPTS, not FLAG, for --repl-options

* Fix typo

* Fix formatting

* Use clearer notation for single and double quotes in docs

This handles geekosaur's review.

* Minor wording change in docs

Co-authored-by: brandon s allbery kf8nh <allbery.b@gmail.com>

---------

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

- Add NeedleHaystackCompare
- Add tests of assertions
- Quote regex pattern
- Add regex tests
- Add assertOutputMatches tests
- Add tests using POSIX character classes
- Rename to TxFwdBwd
- Add isInfixOf predicate to assertOn calls

* print out the "Created semaphore" message only in verbose mode (#10885)

* fixup! Update pr-10936.md

---------

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

bootstrap/bootstrap.py: Added support for multithreaded builds

Mark dedup complex test as flaky

- Sometimes fails with HTTP code 525, SSL handshake failure

always run changelog.d

We've made this a required job to ensure that changelogs are
always valid. But this means we can't use "paths", or PRs that
don't have changelogs will stall because the changelogs job
doesn't get run so it's never considered "succeeded".

This job is cheap, so run it unconditionally. We already know
things are currently valid, so this shouldn't produce any
surprises.

Removes a smattering of, apparent, dead code

Using weeder to find unused definitions. There are a great many more,
but this was an attempt to be relatively conservative in the removal.