{"push_id":1320397429,"size":1,"distinct_size":1,"ref":"refs/heads/backpack","head":"c121c0d21b92e9ac2d8115e9012ea121d74a5084","before":"8de71b2df4ef0c008773a6f53bd75404cc6d5abc","commits":[{"sha":"c121c0d21b92e9ac2d8115e9012ea121d74a5084","author":{"name":"Edward Z. Yang","email":"dd4e0b78926d6a78f28b6daee68e765330ffb0f6@cs.stanford.edu"},"message":"Backpack.\n\nThe spec for the user-facing features can be found in\n\n    https://github.com/ezyang/ghc-proposals/blob/backpack/proposals/0000-backpack.rst\n\nFor Cabal, here are the changes (in dependency order):\n\nDistribution/Utils/Base62.hs\n    Implementation of base-62 encoding, which we use when computing\n    hashes for fully instantiated unit ids.\n\nDistribution/Utils/UnionFind.hs\n    A simple mutable union-find implementation that lives in ST.\n    Will be used for mix-in linking.\n\nDistribution/Utils/MapAccum.hs\n    An implementation of the 'mapAccumM' combinator, which I found\n    useful when implementing some Backpack functionality which\n    could fail.\n\nDistribution/Utils/Progress.hs\n    A copy of the Progress monad from cabal-install solver, which we use\n    to report failure and logging from otherwise pure code.\n\nDistribution/Package.hs\n    The key change is that the UnitId and Module data types change to\n    track the new Backpack concepts (described in the spec).  There\n    are a few extra operations, as well as a type synonym ModuleSubst\n    and operations on it.\n\nDistribution/Backpack.hs\n    This module defines the bulk of other utility functions on UnitId\n    and Module that are useful for operating with Backpack.\n    'improveUnitId' is particularly interesting, as its the way we\n    convert a fully instantiated unit id into a hashed unit id,\n    dropping knowledge of the substitution.\n\nDistribution/Backpack/ModSubst.hs\n    Defines a type class ModSubst for semantic objects that can have\n    module substitutions defined over them.  Helps us define ModSubst\n    functorially.\n\nDistribution/Simple/InstallDirs.hs\n    Fix $libname to use the hashed unit id rather than the full\n    pretty-printed id, since this variable is usually used for\n    file paths.\n\nDistribution/Types/ModuleRenaming.hs\n    We had an old implementation of 'ModuleRenaming', with the\n    assumption that it would be used directly in build-depends; since\n    we have dropped this assumption, we can refactor 'ModuleRenaming'\n    and we do so.  The main idea is to make the data type more directly\n    reflect the syntax you can specify in a Cabal file; so the default\n    renaming and an explicit thinning renaming are now different\n    constructors.  It's no longer possible to use the \"with\" syntax, but\n    it's not necessary either, since we have a special backpack-includes\n    field to specify renamings, so we don't need them to be Monoidal.\n\n    There is also a new syntax for 'hiding', which just lets you hide\n    some modules when including a package. Handy!\n\nDistribution/Types/IncludeRenaming.hs\n    A module naming represents a mapping from module names to module\n    names.  However, an include must track TWO renamings: one for the\n    provisions, and one for the requirements.  'IncludeRenaming'\n    captures both of these renamings.  The current syntax is\n    (prov_rn) requires (req_rn), although some have suggested alternate\n    syntax for this.\n\nDistribution/Backpack/ModuleScope.hs\n    A module scope represents the set of required and provided modules\n    which are \"in scope\", i.e., available for import and mix-in linking.\n    This is not a simple mapping from module name to module, as we're\n    permitted to have conflicting definitions for a module name as long\n    as we don't actually use it.  There's a comment which explains this\n    more clearly in the file.\n\nDistribution/Types/BuildInfo.hs\n    Previously, we recorded 'ModuleRenaming' in @build-depends@, but\n    separated it out when we stored in 'BuildInfo'.  We now go even\n    further, by changing it from a 'Map' (the only thing @build-depends@\n    could support) to a list (so that a package name can be specified\n    multiple times.)  This is good because now a user can instantiate\n    something several times, which is useful in Backpack.\n\nDistribution/Types/Library.hs\n    We renamed 'requiredSignatures' to just 'signatures', to be more\n    direct.  (There is a corresponding syntax change in Cabal files\n    as well.)\n\nDistribution/PackageDescription.hs\n    Dropped the legacy 'lookupRenaming' export; we dont' use it\n    anymore.\n\nDistribution/PackageDescription/Configuration.hs\n    A minor improvement to convenience libraries: we force\n    convenience libraries to NOT be exposed (they're private, after\n    all.)  This helps us on some of our test cases.\n\nDistribution/InstalledPackageInfo.hs\n    New field, @instantiated-with@, which records the full\n    module substitution (it is dropped when we do 'improveUnitId').\n\nDistribution/Simple/GHC/IPI642.hs\n    Handling the new field from above.\n\nDistribution/Backpack/ModuleShape.hs\n    A module shape describes the provisions and requirements of a\n    library.  It's similar to a module scope, except that every\n    export must be unambiguous.\n\nDistribution/Backpack/UnifyM.hs\n    The unification monad, unifiable variants of Module/UnitId (with\n    conversions to and from), and low-level unification operations on\n    them.  Uses 'UnionFind' heavily.\n\nDistribution/Backpack/MixLink.hs\n    The actual implementation of mix-in linking, on top of the\n    unification monad 'UnifyM'.  The key function is 'mixLink',\n    which takes two module scopes and links them together.\n\nDistribution/Types/ComponentLocalBuildInfo.hs\n    Two minor fixes: (1) add 'componentInstantiatedWith' to record\n    how a component was instantiated (analogous to @instantiated-with@)\n    and (2) fix 'componentComponentId' for the new constructors\n    in 'Module'.\n\nDistribution/PackageDescription/Parse.hs\n    Handle syntax change for renaming @required-signatures@ to\n    @signatures@.  Also add a new field @backpack-includes@\n    which can be used to exert fine-grained control over what\n    modules a package brings into scope, include it multiple\n    times, etc.\n\nDistribution/Simple/PackageIndex.hs\n    Maintain a 'ComponentId' index alongside the 'UnitId'\n    index, so we can efficiently look up an indefinite package\n    (which is uniquely identified by a 'ComponentId').\n\n    Also a minor fix to 'moduleNameIndex' to track 'ModuleVar'\n    change.\n\nDistribution/Utils/LogProgress.hs\n    The progress monad, specialized with LogMsg traces and Doc\n    errors.  We provide a function to run such computations,\n    outputting traces according to their 'Verbosity' and 'die'ing\n    if there is an error.\n\nDistribution/Simple/Setup.hs\n    Accept an @--instantiate-with@ flag to ./Setup configure, so\n    that cabal-install can specify how it wants to instantiate\n    a package that it is building.\n\nDistribution/Types/LocalBuildInfo.hs\n    Fix 'localComponentId' to handle new 'UnitId' constructors.\n\nDistribution/Simple/LocalBuildInfo.hs\n    Two fixes:\n        1. Now that we can build a component multiple times with\n        different instantiations, we need to make sure we give each\n        instantiation a different build directory; done in 'buildDir'.\n        2. allLibModules must include every signature in the package,\n        which may NOT be explicitly specified in the Cabal file;\n        we read it off of 'componentInstantiatedWith'.\n\nDistribution/PackageDescription/Check.hs\n    1. Update for required-signatures to signatures renaming\n    2. Replace some uses of libModules with explicitLibModules, as\n       appropriate.\n    3. 'depsUsingThinningRenamingSyntax' replaced with a\n       more direct check to see if @backpack-includes@ was used.\n\nDistribution/Backpack/ComponentsGraph.hs\n    A small helper function for handling the source-level graph\n    of components (so, just the relationship between stanzas\n    in a Cabal file.)  This components graph will eventually get\n    elaborated into a more complex graph with instantiations, etc.\n\nDistribution/Backpack/Id.hs\n    A helper module which now contains the functions for computing\n    component identifiers and compatibility package keys.  This\n    functionality used to live in Distribution.Simple.Configure\n    but I split it out.  There are also adjustments to handle\n    the new Backpack functionality.\n\nDistribution/Backpack/ConfiguredComponent.hs\n    A configured component is one for which we've resolved all\n    source level dependencies (e.g., every entry in build-depends,\n    we know the specific transitive versions of each thing\n    we're going to use.)  That means we have a 'ComponentId' for\n    this component.  This module also contains functions for\n    creating a 'ConfiguredComponent' from a source 'Component'.\n\nDistribution/Backpack/LinkedComponent.hs\n    A linked component is one which we have done mix-in linking\n    for, so we know its 'UnitId' and its 'UnitId' dependencies.\n    This module calls out to mix-in linking to actually do linking.\n    The workhorse, in a sense!\n\nDistribution/Backpack/InstantiatedComponent.hs\n    This module implements the instantiation process, where we\n    zip through all of the fully instantiated components, and\n    recursively instantiate their dependencies, so that we\n    get a separate linked component per thing we need to\n    compile.  This functionality is reimplemented in a different\n    way in cabal-install.\n\nDistribution/Backpack/PreExistingComponent.hs\n    This is a \"interoperability\" data type which identifies\n    precisely the information from a 'LinkedComponent' that\n    can be derived from an 'InstalledPackageInfo'.\n\nDistribution/Backpack/Configure.hs\n    Driver for processing components with Backpack mix-in linking.\n    In goes a source package, out comes a list of\n    'ComponentLocalBuildInfo's which can be used for building.\n\nDistribution/Simple/Program/GHC.hs\n    Two new GHC flags: 'ghcOptInstantiatedWith' @-instantiated-with@ and\n    'ghcOptNoCode' @-fno-code@.\n\nDistribution/Simple/GHC/Internal.hs\n    Set reasonable default values for 'ghcOptInstantiatedWith'\n    and 'ghcOptNoCode', and update 'getHaskellObjects' to take\n    a 'ComponentLocalBuildInfo'.\n\nDistribution/Simple/Program/HcPkg.hs\n    'display' -> 'hashUnitId' to be file system friendly.\n\nDistribution/Simple/LHC.hs\n    Update 'getHaskellObjects' to take 'ComponentLocalBuildInfo'\n\nDistribution/Simple/GHC.hs\n    Teach GHC how to build indefinite libraries, which don't have\n    any code (uses 'whenHasCode' combinator).  In principle this\n    could also be extended to support building anything with no code.\n    Also update 'ghcOptThisUnitId' and 'ghcOptInstantiatedWith'\n    to have correct values.\n\nDistribution/Simple/GHCJS.hs\n    Update 'getHaskellObjects' to take 'ComponentLocalBuildInfo'\n\nDistribution/Simple/Register.hs\n    'display' -> 'hashUnitId' to be file system friendly,\n    and correctly setup 'instantiatedWith' in 'InstalledPackageInfo'.\n    Also ensure that there are no duplicate entries in 'depends'\n    (I couldn't find the root cause for duplication, so I just\n    put the test here.)\n\nDistribution/Simple/PreProcess.hs\n    Cosmetic update to print the ModuleSubst hash when building.\n\nDistribution/Simple/Configure.hs\n    Plumbing work; some functions were factored out to modules\n    you've seen already, makes a call to Distribution.Backpack.Configure\n    to setup ComponentLocalBuildInfo.\n\nDistribution/Simple/Build.hs\n    1) requiredSignatures -> signatures\n    2) Create empty hsig files for each requirement of the library\n       (part of the GHC-Cabal contract: we always have a source file\n       for everything GHC does work on)\n    3) Handle componentInstantiatedWith addition when we create a fake\n       library ComponentLocalBuildInfo for test suites\n    4) Debug output printing out the installed package info when we\n       register information.\n\nDistribution/Simple/Haddock.hs\n    1) Bugfix so that we get library source files from the correct\n       directories (it was wrong previously; it only ever looked\n       in the library directory)\n    2) Search for hsig/lhsig files when looking for source files\n\nDistribution/Simple/SrcDist.hs\n    Cosmetic update to print the ModuleSubst hash when preprocessing\n\nSigned-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>","distinct":true,"url":"https://api.github.com/repos/ezyang/cabal/commits/c121c0d21b92e9ac2d8115e9012ea121d74a5084"}]}
{"actor":{"display_login":"ezyang"}}