This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated .
  1. 26 Oct, 2016 4 commits
    • Oleg Grenrus's avatar
      Lens additions · ee5e64fb
      Oleg Grenrus authored
      ee5e64fb
    • Oleg Grenrus's avatar
      PVP alex bound · 0ee50bc6
      Oleg Grenrus authored
      0ee50bc6
    • Oleg Grenrus's avatar
      Hide StructDiff behind the flag · 722e030f
      Oleg Grenrus authored
      722e030f
    • Oleg Grenrus's avatar
      Parsec parser · 512db606
      Oleg Grenrus authored
      - Initial import of stuff
      - Add hackage index parsing test for parsec
      - We can parse name and version
      - Add generics-sop dep
      - Use D.C.Prelude
      - Add StructDiff
      - Fix integral
      - Add Parsec -class
      - Add licence parsing
      - Free text fields (parsed as ascii atm)
      - Better StructDiff
      - Parsec BuildType
      - Implement VersionRange parser
      - Section parsing first steps
      - Sketch parseCondTree
      - more sec parsing
      - Module name
      - hs-source-dirs
          ::: composition/0.1/composition.cabal
          ::: composition/0.2/composition.cabal
          ::: composition/0.2.1/composition.cabal
          ::: composition/1.0.0.0/composition.cabal
      - PError (Position 20 1) "Unknown section: \"source-repository\""
      - Parses condition
      - Add some notes, address few comments
      - Install alex on linux travis
      - Make ParseResult strict state monad
      - Use withinVersion
      - No warnings
      - Move to Distribution.PackageDescription.Parsec.FieldDescr
      - extensions
      - SourceRepo (sans kind) parsing
      - RepoKind
      - Few more stuff
      - Add Distribution.Compat.Parsec
      - We can parse all 'composition*' packages cabal files \o/
      - fromUtf8BS
      - Clean up abit
      - More stuff
      - And more stuff
      - Traling whitespace :(
      - Executables
      - Benchmarks
      - spaceListField
      - Parse flag sections
      - a ~ Char,
      - tested with
      - package description x-fields
      - Conditions
      - reformat
      - Handle old syntax
      - More fields
      - More stuff
      - ^co ok,
      - more stuff
      - ^c ok
      - some of hackage ok
      - A-Z ok
      - Works [A-al)
      - to the h
      - rest of Hackage
      - Introduce parsec -flag
      - Count warnings
      - Verify we get not less warnings from parsec parser
      - fixup! Introduce parsec -flag
      - Warn about old/new syntax and cabal-version
      - Invalid UTF warning
      - Deprecated fields
      - Fix meta
      - Move transformers dep under parsec flag
      - Add parsec travis job
      512db606
  2. 20 Oct, 2016 1 commit
  3. 19 Oct, 2016 1 commit
  4. 18 Oct, 2016 4 commits
  5. 14 Oct, 2016 1 commit
  6. 08 Oct, 2016 1 commit
  7. 06 Oct, 2016 6 commits
    • Edward Z. Yang's avatar
      45d75e1f
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      Add the bulk of the new Backpack code · f2840cca
      Edward Z. Yang authored
      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'.
      f2840cca
    • Edward Z. Yang's avatar
      Replace the module renaming/thinning system · 1017f710
      Edward Z. Yang authored
      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.
      1017f710
    • Edward Z. Yang's avatar
      Add D.Backpack module with IndefUnitId and IndefModule types · fdf30f80
      Edward Z. Yang authored
      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.
      fdf30f80
    • Edward Z. Yang's avatar
      Add more reexported module tests · 6059c6b3
      Edward Z. Yang authored
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      6059c6b3
  8. 29 Sep, 2016 1 commit
  9. 26 Sep, 2016 2 commits
    • Herbert Valerio Riedel's avatar
      Introduce `Distribution.Compat.Prelude.Internal` + WARNING · 4c730f58
      Herbert Valerio Riedel authored
      This unexposes `Distribution.Compat.Prelude` again, and adds
      an exposed `.Internal` module which reexports the `.Prelude` module with
      an attached module-level `WARNING` pragma.
      
      This way users are discouraged to use this in `Setup.hs` files as they'd
      see compile warning like:
      
          Foo.hs:19:1-55: warning: [-Wdeprecations]
            Module ‘Distribution.Compat.Prelude.Internal’:
              This modules' API is not stable. Use at your own risk, or better yet, use @base-compat@!
      
      In `cabal-install` we import the `.Internal` module exactly once, and
      use -Wno-deprecations to suppress that the warning of that single
      import.
      4c730f58
    • Herbert Valerio Riedel's avatar
      Introduce `Distribution.Client.Compat.Prelude` · 82a22706
      Herbert Valerio Riedel authored
      This is supposed to become more or less a superset of Cabal's
      `Distribution.Compat.Prelude`.
      
      As a side-effect,t his exposes `Distribution.Compat.Prelude` from the
      Cabal library (which may be actually a good thing, as it may be useful
      module to Setup.hs writers).
      82a22706
  10. 22 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Update default-language & avoid default-extensions (#3880) · f87738df
      Herbert Valerio Riedel authored
      This upgrades the `default-language: Haskell98` to `Haskell2010`
      and removes `default-extensions: RankNTypes, FlexibleContexts`
      in favor of adding `LANGUAGE` pragmas where needed.
      
      Moroever, this also drops `LANGUAGE` pragmas which have become redundant
      due to `Haskell2010` (specifically, `EmptyDataDecls`,
      `ForeignFunctionInterface` and `PatternGuards`)
      
      Finally, an `other-extensions` specification is put in place for the
      `Cabal` library component.
      
      This helps loading up files directly in GHCi, such as e.g. `ghci Setup.hs`
      without having to specify `-X...` flags.
      f87738df
  11. 18 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Use enabledBuildInfos rather than allBuildInfo. · b17a45e9
      Edward Z. Yang authored
      
      
      In many places, we incorrectly used allBuildInfo, which
      returns all BuildInfos that are buildable, and not
      necessarily the ones we are actually going to *build*.
      This used to "mostly do the right thing" because we
      literally edited the PackageDescription to nub out things,
      so you wouldn't see non-enabled components anyway.  However
      when I added support for per-component configure, I stopped
      editing the PackageDescription, which meant all of these
      uses were wrong.
      
      So, I updated them to do the right thing. Note that there
      are still uses of allBuildInfo in Check, but that probably
      requires a closer look.
      
      Fixes #3847.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      b17a45e9
    • Edward Z. Yang's avatar
      Refactor ComponentEnabledSpec into ComponentRequestedSpec. · d03fe594
      Edward Z. Yang authored
      
      
      In the previous documentation for 'ComponentEnabledSpec', I claimed
      that enabled components were buildable, as well as requested
      by the user.  In the course of working on #3847, however,
      I realized that I hadn't actually *checked* that the component
      was buildable anywhere.  In particular, the 'ComponentDisabled'
      reason was *never used*.  This mostly didn't cause problems,
      however, because when we 'flattenPD' all non-buildable components
      get deleted, so you basically never actually have a non-buildable
      'Component'.
      
      But it still seemed a bit silly, so I fixed it by doing this:
      
      1) I introduce a new concept of a component being requested,
      which captures the use of --enable-tests and friends.  This
      does NOT imply buildability.  Renamed ComponentEnabledSpec
      to ComponentRequestedSpec
      
      2) A component is enabled if it is requested and buildable.
      If you give me a Component and a ComponentRequestedSpec I
      can tell you if it's enabled.  However, if you give me a
      ComponentName I can't, because I have no idea if it's buildable.
      
      3) Stopped reexporting ComponentRequestedSpec from
      Distribution.Simple.LocalBuildInfo
      
      4) Added a test for attempting to specify a non-buildable
      component as a target.  The test is accepting suboptimal
      output at the moment, see #3858.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d03fe594
  12. 10 Sep, 2016 1 commit
  13. 08 Sep, 2016 2 commits
    • Edward Z. Yang's avatar
      Provide useful call-stacks over all IO code. · 48a0d6ce
      Edward Z. Yang authored
      
      
      The key idea is that we define:
      
          type IO a = HasCallStack => Prelude.IO a
      
      and voila, call stacks are maintained across all IO!  You can
      look at the stacks using -v"debug +callstack".
      
      There are a number of IO functions for which the call stack is
      never used.  They are explicitly annotated using NoCallStackIO.
      Maybe some day they will use call stacks and we can change their
      types.  Similarly, there are a number of functions which do
      have type IO, but then suppress the redundant constraint error
      using "_ = callStack". Maybe some day we will attach call
      stacks to the exceptions we throw.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      48a0d6ce
    • Edward Z. Yang's avatar
      Add support for extended verbosity specification -v"debug +callsite" · 83c93c10
      Edward Z. Yang authored
      This patch uses CallStack support in GHC 7.10 and GHC 8.0 to make
      it possible to get stack traces when we log output.
      
      This is the bare minimum to make this patch useful: there is
      plenty of tuning that can be done.  For example:
      
      * Insertions of withFrozenCallStack can help make the "callsite" output
        more useful, though be careful, we lose all stack information at that point!
      
      * Insertions of 'WithVerbosity', which will let us get deeper stacks
        (at the moment, they are basically always 1-deep.)
      
      Fixes #3768.
      
      CC @23Skidoo
      
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      83c93c10
  14. 05 Sep, 2016 1 commit
  15. 01 Sep, 2016 1 commit
  16. 21 Aug, 2016 2 commits
    • Edward Z. Yang's avatar
    • Edward Z. Yang's avatar
      One-component configure, fixes #2802. · a090a494
      Edward Z. Yang authored
      Described in: https://github.com/ghc-proposals/ghc-proposals/pull/4
      
      
      
      ./Setup configure now takes an argument to specify a specific
      component name that should solely be configured.
      
      Most of the gyrations in Configure are all about making it so that
      we can feed in internal dependencies via --dependency.
      
      I dropped the package name match sanity check to handle convenience
      library package name munging.  Consider an internal library named
      'q' in package 'p'.  When we install it to the package database,
      we munged the package name into 'z-p-z-q', so that it doesn't
      conflict with the actual package named 'q'.  Now consider when
      we feed it in with --dependency q=p-0.1-hash-q.  Previously,
      Cabal checked that the 'q' in --dependency matched the package
      name in the database... which it doesn't. So I dropped the check.
      
      I also had to make register/copy unconditionally install internal
      libraries; otherwise you can't refer to them from later builds.
      
      Also a miscellaneous refactor: convenience libraries are printed with a
      "header" stanza now (not really a stanza header).
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      a090a494
  17. 11 Aug, 2016 1 commit
    • fmaste's avatar
      Add new 'autogen-modules' field · c0108673
      fmaste authored
      Modules that are built automatically at setup, like Paths_PACKAGENAME or others created with a build-type custom, appear on 'other-modules' for the Library, Executable, Test-Suite or Benchmark stanzas or also on 'exposed-modules' for libraries but are not really on the package when distributed. This makes commands like sdist fail because the file is not found, so with this new field modules that appear there are treated the same way as Paths_PACKAGENAME was and there is no need to create complex build hooks.
      Just add the module names on 'other-modules' and 'exposed-modules' as always and on the new 'autogen-modules' besides.
      c0108673
  18. 26 Jul, 2016 2 commits
  19. 23 Jul, 2016 2 commits
    • Edward Z. Yang's avatar
      Refactor LocalBuildInfo interface. · d94ddc0e
      Edward Z. Yang authored
      
      
      This is an omnibus patch, with the overall goal of making
      LocalBuildInfo Great Again.  The essential ideas:
      
      * New type 'TargetInfo' which bundles together 'ComponentLocalBuildInfo'
        and 'Component'.  Eventually, it will also record file paths / module
        targets.  This data structure is basically what you want; a lot of
        old Cabal code did lots of gyrations converting from
        'ComponentLocalBuildInfo' to 'Component' and vice versa, now
        it's all centralized.
      
      * The "new" API for 'LocalBuildInfo' is in
        "Distribution.Types.LocalBuildInfo".  The general principle
        is, where we previous dealt in 'ComponentLocalBuildInfo',
        we now deal in 'TargetInfo'.  There are shockingly few
        functions we need!
      
      * I've restored 'componentsConfigs' to its Cabal 1.24 signature
        for BC.
      
      * I killed a number of unused functions from "Distribution.Simple.LocalBuildInfo":
        'getLocalComponent', 'maybeGetDefaultLibraryLocalBuildInfo',
        'maybeGetComponentLocalBuildInfo', 'checkComponentsCyclic' and
        'enabledComponents'.  For each I checked on Hackage that they were
        not used.
      
      * 'getComponentLocalBuildInfo', 'withComponentsInBuildOrder' and
        'componentsInBuildOrder' are deprecated to encourage people
        to instead use the 'TargetInfo's to finger which components
        they want built.
      
      * 'ComponentLocalBuildInfo' now stores internally the computed
        'componentInternalDeps', so that 'LocalBuildInfo' can simply store
        a graph of 'ComponentLocalBuildInfo'.
      
      * The code in Configure has been streamlined to use our new Graph
        data type to great success.
      
      * The type of 'runTest' changed to take a 'ComponentLocalBuildInfo',
        bringing it more in line with everything else.
      
      * New function 'readTargetInfos' which combines 'readBuildTargets'
        and 'checkBuildTargets', which is what you really wanted anyway.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d94ddc0e
    • Herbert Valerio Riedel's avatar
      Implement `--allow-older` (dual to `--allow-newer`) (#3466) · 5944c3e9
      Herbert Valerio Riedel authored
      This implements the flag `--allow-older` which is the analogous to
      `--allow-newer` acting on lower bounds.
      5944c3e9
  20. 22 Jul, 2016 2 commits
  21. 14 Jul, 2016 1 commit
  22. 11 Jul, 2016 1 commit