GitLab

These are libraries which don't have any code (uses 'whenHasCode'
combinator).  In principle this could also be extended to support
building anything with no code.

Also update 'ghcOptThisUnitId' and 'ghcOptInstantiatedWith' to
have correct values.

Count signatures as modules that we have to find, and when searching for
modules, look for .hsig or .lhsig files (in addition to the usual .hs
.lhs files)

Part of the GHC/Cabal contract is that we always have a source file
for everything GHC works on.

Now that we can build a component multiple times with
different instantiations, we need to make sure we give each
instantiation a different build directory; done in 'buildDir'.

Correctly setup 'instantiatedWith' in 'InstalledPackageInfo'.

Also ensure that there are no duplicate entries in 'depends'
(I couldn't find the root cause for duplication, so I just
put the test here.)

These may NOT be explicitly specified in the Cabal file;
we read it off of 'componentInstantiatedWith'.

Many of the configure functions were factored out and moved to the new
Backpack modules. The new configure action makes a call to
Distribution.Backpack.Configure to setup the ComponentLocalBuildInfo.

Also add an @--instantiate-with@ flag to ./Setup configure, so that
cabal-install can specify how it wants to instantiate a package that
it is building.

Also do the minimal necessary adjustments in cabal-install.

This will shortly be used in the package configuration step.

Distribution/Utils/Progress.hs
    A copy of the Progress monad from cabal-install solver, which we use
    to report failure and logging from otherwise pure code.

Distribution/Backpack/ModSubst.hs
    Defines a type class ModSubst for semantic objects that can have
    module substitutions defined over them.  Helps us define ModSubst
    functorially.

Distribution/Backpack/ModuleScope.hs
    A module scope represents the set of required and provided modules
    which are "in scope", i.e., available for import and mix-in linking.
    This is not a simple mapping from module name to module, as we're
    permitted to have conflicting definitions for a module name as long
    as we don't actually use it.  There's a comment which explains this
    more clearly in the file.  These are based off of 'IndefModule'
    because not all modules in scope are necessarily fully instantiated.

Distribution/Backpack/ModuleShape.hs
    A module shape describes the provisions and requirements of a
    library.  It's similar to a module scope, except that every
    export must be unambiguous; it too is based off of 'IndefModule'.

Distribution/Backpack/FullUnitId.hs
    An 'IndefUnitId' is not guaranteed to record a module substitution
    (it could be opaquely represented as a hash); a 'FullUnitId',
    however, IS guaranteed to do so.  Given, for example, an installed
    package database, we can map opaque 'UnitId' into their expanded
    representation.  This can be important to handle obscure unification
    problems when mix-in linking.

Distribution/Backpack/UnifyM.hs
    The unification monad, unifiable variants of Module/UnitId (with
    conversions to and from), and low-level unification operations on
    them.  Uses 'UnionFind' heavily.

    There is some commented out support for handling recursive
    unification.  At present there is no surface syntax for representing
    such situations.  (We would also need DFA minimization to
    canonicalize these regular trees.)

Distribution/Backpack/MixLink.hs
    The actual implementation of mix-in linking, on top of the
    unification monad 'UnifyM'.  The key function is 'mixLink',
    which takes two module scopes and links them together.

Distribution/Utils/LogProgress.hs
    The progress monad, specialized with LogMsg traces and Doc
    errors.  We provide a function to run such computations,
    outputting traces according to their 'Verbosity' and 'die'ing
    if there is an error.

Distribution/Backpack/ComponentsGraph.hs
    A small helper function for handling the source-level graph
    of components (so, just the relationship between stanzas
    in a Cabal file.)  This components graph will eventually get
    elaborated into a more complex graph with instantiations, etc.

Distribution/Backpack/Id.hs
    A helper module which now contains the functions for computing
    component identifiers and compatibility package keys.  This
    functionality used to live in Distribution.Simple.Configure
    but I split it out.  There are also adjustments to handle
    the new Backpack functionality.

Distribution/Backpack/ConfiguredComponent.hs
    A configured component is one for which we've resolved all
    source level dependencies (e.g., every entry in build-depends,
    we know the specific transitive versions of each thing
    we're going to use.)  That means we have a 'ComponentId' for
    this component.  This module also contains functions for
    creating a 'ConfiguredComponent' from a source 'Component'.

Distribution/Backpack/LinkedComponent.hs
    A linked component is one which we have done mix-in linking
    for, so we know its 'IndefUnitId' and its 'IndefUnitId'
dependencies.
    This module calls out to mix-in linking to actually do linking.
    The workhorse, in a sense!

Distribution/Backpack/ReadyComponent.hs
    This module implements the instantiation process, where we
    zip through all of the fully instantiated components, and
    recursively instantiate their dependencies, so that we
    get a separate linked component per thing we need to
    compile, and also finishes off any top-level indefinite
    components.  This gives us the final 'UnitId' for our
    units.

    This functionality is reimplemented in a different way in
    cabal-install; the assumptions are slightly different (in
    particular, in the library we can't assume we have access to all
    packages to build them; but in cabal-install we can assume it) so I
    didn't try to abstract over both implementations.

Distribution/Backpack/PreExistingComponent.hs
    This is a "interoperability" data type which identifies
    precisely the information from a 'LinkedComponent' that
    can be derived from an 'InstalledPackageInfo'.

(1) add 'componentInstantiatedWith' to record how a component was
instantiated (analogous to @instantiated-with@) and
(2) fix 'componentComponentId' for the new constructors in 'Module'.

We had an old implementation of 'ModuleRenaming', with the
assumption that it would be used directly in build-depends; since
we have dropped this assumption, we can refactor 'ModuleRenaming'
and we do so.  The main idea is to make the data type more directly
reflect the syntax you can specify in a Cabal file; so the default
renaming and an explicit thinning renaming are now different
constructors.  It's no longer possible to use the "with" syntax, but
it's not necessary either, since we have a special backpack-includes
field to specify renamings, so we don't need them to be Monoidal.

There is also a new syntax for 'hiding', which just lets you hide
some modules when including a package. Handy!

Previously, we recorded 'ModuleRenaming' in @build-depends@, but
separated it out when we stored in 'BuildInfo'.  We now go even
further, by changing it from a 'Map' (the only thing @build-depends@
could support) to a list (so that a package name can be specified
multiple times.)  This is good because now a user can instantiate
something several times, which is useful in Backpack.

Also add the new field @backpack-includes@ which can be used to exert
fine-grained control over what modules a package brings into scope,
include it multiple times, etc.

In the .cabal checks, replace 'depsUsingThinningRenamingSyntax' with a
more direct check to see if @backpack-includes@ was used.

Dropped the legacy 'lookupRenaming' export from ModuleRenaming and
PackageDescription; we will shortly not use it anymore. As an
intermediate hack we have a local definition in Configure, but this
will go away shortly.

Change of .cabal file syntax: rename @required-signatures@ field to
just @signatures@. Update the parser and error messages that mention
the field.

Also rename the corresponding field in the Library type.

New field, @instantiated-with@, which records the full
module substitution (it is dropped when we do 'improveUnitId').

For flexibility in the case of indefinite packages, some
occurences of Module are relaxed to IndefModule (exposedReexport).
This is just for convenience; in the case of a definite package
these reexports and instantiations are guaranteed to be 'Module's.

This patch also includes the minimal changes in other modules
needed due to the representation change.

New GhcOptions fields, 'ghcOptInstantiatedWith' for
@-instantiated-with@ and 'ghcOptNoCode' for @-fno-code@.

We will use this when building indefinite libraries.

This module defines the key data types 'IndefUnitId' and
'IndefModule', which represent components which are partially
instantiated with holes in them.  The intent is that they
can be substituted over (Distribution.Backpack.ModSubst),
and once all the holes are filled they can be improved into
proper 'UnitId's, which can then be installed.

Also add Distribution.Util.Base62 module containing an
implementation of base-62 encoding, which we use when
computing hashes for fully instantiated unit ids.

'SimpleUnitId' constructor renamed to 'UnitId', and augmented
with a new field 'Maybe String' recording a hash that uniquely
identifies an instantiated unit of the library 'ComponentId'.
'UnitId' can't be used to represent partially instantiated
unit identifiers; see Distribution.Backpack for how we handle that.

Previous uses of 'SimpleUnitId' should now use 'newSimpleUnitId'.
'unitIdComponentId' folded into a record selector for 'ComponentId'.

Rather than reusing the one for ComponentId.

We force convenience libraries to NOT be exposed (they're private,
after all.)  This will help us on some of our test cases.

Eliminating the use of deprecated 'getComponentLocalBuildInfo'

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

cabal.project: Add a constraint on unix.

On recent OS X, Cabal does not work correctly because it assumes
that a permission denied error when reading permissions on
executables, resulting in errors like "Setup: /usr/bin/ar: permission denied".

The proximal fix for this is to add a constraint on unix when we build
Cabal/cabal-install to avoid building with the buggy version of unix.
But this causes other problems:

- Bumping the version of unix means that our local build of Cabal
  will depend on things from the store.  But we weren't passing
  this to GHC when compiled Setup.hs for Cabal's package-tests.
  Set CABAL_PACKAGETESTS_DB_STACK env var explicitly to point
  to the right locations.

- The new configuration of versions exposed some bugs in some
  macro expanded code in cabal-install; we qualified those
  imports to squash unused warnings.

- The cabal-install integration-tests occasionally use Cabal from
  the system GHC.  Since this will never work on OS X, we just
  skip the tests in those cases.
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

PackageEnvironment: Sort constraints in produced freeze file

This makes freeze files a bit more version-control-friendly.

Optimise Distribution.Version.mkVersion

Add unit tests for solver stanza preferences.

This resulted in some two-bytes utf8 encodings to be decoded
into U+FFFD unintentionally (such as e.g. U+0142).

With this fix, the property

    [ c | c <- [minBound..maxBound]
        , c < '\xD800' || c >= '\xE000' -- surrogate pair codes
        , (decodeStringUtf8 . encodeStringUtf8) [c] /= [c]
        ] == ['\xfffe','\xffff']

holds. It's not clear to me why U+FFFE and U+FFFF ought to be singled
out. Needs more investigation.

TODO: testsuite coverage

TODO: we need more unit-tests to catch this; also I noticed
that `decodeStringUtf8` (which was previously named `fromUTF8BSImpl`)
appears to have been broken for quite some time.

For one this compensates for `Word` being exported from `Prelude` only with
base >= 4.8, and moreover this brings the well-known {Int,Word}{8,16,32,64}
names into scope by default when using the Compat.Prelude.

This changes the representation of module names from `[[Char]]`
(e.g. `Control.Monad.Fail` is decomposed into `["Control","Monad","Fail"]`)
which results in many small heap objects, to a strict list of `ShortText`s.

`ModuleName` was already an opaque type, so there is no visible change
to the exposed API.