GitLab

Add TargetPackageNamed, like TargetPackage but for known packages
within the project that are only specified by name. This includes the
extra-packages from the @cabal.project@ file.

It does not include indirect deps or other packages from hackage. That
will be covered by a separate constructor.

This replaces the previous TargetPackageName constructor which was part
of a much more limited implementation of the same general idea.

We'll need display of component kind both for component names (as now)
and also directly for ComponentKind. Rename so the naming is sane.

We are about to generalise KnownPackage in such a way that it can no
longer be an instance of Package. The extra constructor will only hold
a PackageName, not a full PackageId.

In addition, whenever we get a KnownPackage, we do case analysis and
record pattern matching to select the bits we need. This is in
preparation for adding the second constructor. We switch to record
pattern matching rather than field names as functions since those
functions will become partial once we add the second constructor.

That is, the TargetPackage instead of having a single PackageId contains
a [PackageId].

Ultimately this will allow us to support multiple .cabal files in a
single directory. But the real reason to do this generalisation now is
that it helps with the TargetImplicitCwd case. For the implicit CWD case
we need to be able to parse the target whether or not there is a package
in the CWD. So the simplest solution is to pass in all the local CWD
packages (though typically only 0 or 1) and put all of them in. Then at
the end we can check if in fact there were 0 and fail.

When we do want to support multiple .cabal files in a dir, we'll also
need to adjust the project config code, and extend the syntax slightly
so that we render as the package location for the case of multiple
packages.

It is unnecessary now that we do not put the whole KnownPackage into the
TargetSelector. It not being recursive also makes it possible to have a
Show instance, which is handy.

Previously the TargetSelector type had a type param for the type of the
package that it referred to. In particular we used it with types like:

type Matcher  = ... -> Match (TargetSelector KnownPackage)
type Renderer = TargetSelector PackageId -> ...

However we are about to extend the TargetSelector so that it does not
just refer to one form of package (e.g. KnownPackage) but can refer to
packages via various different forms and partial information. So it no
longer makes sense to have TargetSelector be paramaterised by the
different states of the one kind of package it refers to, as there are
now many kinds. So in preparation for that we simplify it so that it is
equivalent to always using TargetSelector PackageId, and we remove the
type paramater.

To KnownPackage and KnownComponent. This is in preparation for
extending  KnownPackage by adding more constructors for known package
names.

Bundle up what we had been passing as separate args into a single
KnownTargets type, and separate out some utils for constructing it.

Instead of two constructors MatchExact and MatchInexact we now have one
Match constructor with a field of data MatchClass = Inexact | Exact.
This factoring helps simplify several other functions where we treat
them uniformly or according to the Ord instance.

The real ulterior motive however is that we'd like to introduce a third
Match class value between Inexact and Exact. This refactoring is a
prerequisite to that, to avoid a combinatorial explosion of cases.

Initialize globalCacheDir in baseSavedConfig

This reverts commit bdb51a36.

Herbert Valerio Riedel authored May 21, 2017 and Mikhail Glushenkov committed Nov 03, 2017

(cherry picked from commit 0a28ab6a)

Version range refactor

Add s/cmm-sources + extra-bundled-libraries

Apply 'any' qualifier to new-freeze constraints (fixes #4832).

Adds defaultMainWithHooksNoReadArgs

'makeAbsolute' is not compatible with old versions of 'directory' and
we know at this place in the code that the directory we refer to does
exist, so the potential exception is not a problem.

Fixes #4606.

(cherry picked from commit 560903cf)

Not absolutely happy with this solution. I fail to come up with a better one though.
The issue is that for some libraries, you might want to have _debug, _p, _l, as well as _thr_debug, _thr_p, _thr_l flavours.

# Conflicts:
#	Cabal/Distribution/PackageDescription/Parsec/FieldDescr.hs

# Conflicts:
#	Cabal/Distribution/PackageDescription/Check.hs
#	Cabal/Distribution/PackageDescription/Parsec/FieldDescr.hs
#	Cabal/Distribution/Parsec/Types/FieldDescr.hs
#	Cabal/doc/developing-packages.rst

new-install: nonlocal exes

[ci skip]

RFC: Relax coding guideline regarding module imports

This is a refactoring abstracting `FlagAssignment` while retaining its
external appearance as much as possible (i.e. same Read/Show/Binary
instances etc).

Later we can attach new instances, enforce internal invariants (like
e.g. uniqueness of flagnames), switch out the internal
representation (maybe to `Data.Map`), etc more easily.

Implement native DNS hackage-security bootstrap via resolv/windns packages

I notice imports like

    import qualified Text.PrettyPrint as Disp
          ( Doc, render, char, text )

which seem overly precise to me, when `Disp.` is only used
locally as a module prefix, and there's no other imports sharing
the same module prefix.

Instead, it should suffice to either use

    import qualified Text.PrettyPrint as Disp

or

    import Text.PrettyPrint
          ( Doc, render, char, text )

or in rare cases even

    import Text.PrettyPrint as Disp
          ( Doc, render, char, text )

Hence this relaxes the coding guidelines to allow these simpler forms
to be used.

[skip ci]

...via the new @windns@ package (which provides a compatible subset
of the @resolv@ API)

The flag is renamed from `resolv` to `native-dns`