This project is mirrored from Pull mirroring updated .
  1. 03 Nov, 2018 5 commits
  2. 08 Jun, 2018 1 commit
  3. 13 Mar, 2018 1 commit
  4. 15 Aug, 2017 1 commit
    • Oleg Grenrus's avatar
      Use parsec, drop parsec flag · 5e4f4d58
      Oleg Grenrus authored
      - Manually generate Lexer.hs
      - Temporarily disable parser-hackage-tests on appveyor (needs
      - Add root Makefile to handle commmon dev tasks (genering Lexer.hs)
  5. 10 Aug, 2017 1 commit
  6. 09 Aug, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Refactor 'RelaxDeps' to avoid semantic ambiguity of mempty value · 4066ea7a
      Herbert Valerio Riedel authored
      This removes the redundancy between `RelaxDepsNone` and
      `RelaxDepsSome []` by removing `RelaxDepsNone`.
      This way we avoid the risk of subtle bugs that can occur if the same
      semantic value can be expressed in a non-unique way.
      A further step to normalise the type would be to turn `[RelaxedDep]`
      into `Set RelaxedDep`, but there is no operation that would
      significantly benefit from that yet.
  7. 18 May, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Remove --allow-{newer,older} support from Cabal · a95b8f4e
      Herbert Valerio Riedel authored
      This is a preparatory refactoring needed for future work such as #4203.
      I've refrained from doing additional cleanups in order to keep this a
      refactoring that mostly moves around blocks of code mostly
      unchanged (except for whitespace), and make it easier to review.
      This feature was originally implemented because its lack was complained
      about by Stack/Stackage developers. However, after it got implemented it
      was never really being used; what's more, it's causing us overhead for
      no benefit as well as blocking us improving the implementation via the
      likes of #4203.
      Closes #3581
  8. 04 May, 2017 1 commit
    • Francesco Gazzetta's avatar
      merged imports · 58cd8e9c
      Francesco Gazzetta authored
      not all imports can be merged because some are inside ifdefs, but all
      the safe one are now merged
  9. 17 Mar, 2017 1 commit
    • Edward Z. Yang's avatar
      Refactor MungedPackageId and PackageIndex. · f4ded04f
      Edward Z. Yang authored
      This makes the necessary changes to 4dc0f30fc36914ee2f01bde016bee98b8e0bb0bb
      to handle component configuring correctly.  It probably is a good step
      towards pkg:lib style dependencies.
      The big ideas:
      * There's a new AnnotatedId type, which is any identifier (like
        ComponentId), but also with a PackageId and ComponentName.
        It's a bit like ConfiguredId, but ConfiguredId is specialized
        for ComponentId.  There's a conversion function
      * We adopt a totally new strategy for handling MungedPackageId in
        InstalledPackageInfo.  Rather than store the munged package
        identifier in IPI, we NEVER store it, instead computing it
        from the package name and library name (which are stored.)
        There is now code to PARSE a munged package name into these
        two components, so that when we read 'name' we get the
        correct info.  The resulting code is splendidly clear.
      * Some places where we took a ComponentName (notably
        computeCompatPackageName) we now take 'Maybe UnqualComponentName'.
        This is more accurate, because compatibility package names are
        only computed for libraries, not other components.  Some code
        in Distribution.Backpack.ReadyComponent is partial now,
        but the invariants should hold up.
      * A number of places where MungedId was applied, I undid them.
        Most notable are macro generation (that should be PACKAGES,
        not components) and mkLegacyUnitId (since REALLY old style
        unit identifiers, we won't support internal libraries anyway.)
      * Many functions in PackageIndex are monomorphized to
        InstalledPackageInfo.  Fortunately cabal-install's usage
        still works.
      * Distribution/Client/SolverPlanIndex.hs, not used by anyone,
        got the axe.
      * Dependency solving has a hack to solve the problem of how to
        interpret installed internal libraries in the package database.
        The basic idea is that, although in most cases where we used
        a MungedId, we say it explicitly, in the SOLVER, we munge
        *installed package names* only, and keep the type PackageName.
        It's a hack, but the alternative is to write a lot more code.
        Note that is MORALLY PN is indeed a PackageName, since we really
        are solving for honest to goodness packages, not components!
        See Note [Index conversion with internal libraries] for more
      * ConfiguredId now records the ComponentName.  This is quite important,
        because we need to use it to figure out how we are going to phrase
        --dependency.  In fact, it is a miracle that this worked at all
        (and it only worked because of a very skeevy update to the PackageId
        in the creation of ConfiguredComponent).  Irritatingly, this must
        be a Maybe ComponentName, because a ConfiguredId MIGHT refer to
        a setup component. Very distressing.
      Signed-off-by: default avatarEdward Z. Yang <>
  10. 19 Feb, 2017 2 commits
  11. 03 Feb, 2017 1 commit
  12. 26 Jan, 2017 1 commit
  13. 12 Jan, 2017 1 commit
  14. 07 Jan, 2017 1 commit
    • Robert Henderson's avatar
      Added qualifier to 'PackageConstraint' data type. · 79d562bf
      Robert Henderson authored
      Refactored PackageConstraint in two ways:
       1) split it into a package name and a 'PackageProperty' to make
          the code a bit cleaner;
       2) changed PackageName to 'Qualified PackageName'.
      Added a Binary instance for Qualifier in PackagePath.hs (needed
      for PackageConstraint).
      Added pretty-printing code for PackageConstraint.
      For now, all the code that creates a PackageConstraint just sets
      the qualifier to 'unqualified', so this commit will not change
      the external behaviour of cabal-install.
  15. 18 Nov, 2016 1 commit
  16. 14 Nov, 2016 1 commit
  17. 28 Sep, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Make `Version` type opaque (#3905) · bb2026c4
      Herbert Valerio Riedel authored
      Similiar to dabd9d98 which made
      `PackageName` opaque, this makes `Distribution.Version.Version` opaque.
      The most common version numbers occuring on Hackage are 3- and
      4-part versions. This results in significant Heap overhead due to
      `Data.Version`'s inefficient internal representation.
      So like the `PackageName` commit, this commit is a preparatory commit to
      pave the way for replacing `Version`'s internal representation by a
      representation with a memory footprint which can be an order of
      magnitude smaller.
      Finally, this also adds a new functor-like convenience function
          alterVersion :: ([Int] -> [Int]) -> Version -> Version
      for modifying the version number components.
  18. 27 Sep, 2016 1 commit
    • Arian van Putten's avatar
      Make interactive setup delegate CTRL+C · 005f6dfa
      Arian van Putten authored
      Fixes #3899
      When cabal new-repl spawns ghci, it spawns this as a subprocess.
      In UNIX like systems, if a CTRL+C is sent to this child process
      it also bubbles up to the parent process, causing it to terminate.
      Also see
      However, this is not what we want for interactive subprocesses.
      Interactive processes usually define their own handlers for CTRL+C,
      for example GHCi uses CTRL+C to reset the input buffer. So instead
      of terminating on CTRL+C we want to delegate CTRL+C to GHCi
      and let it do its thing.
      Luckily, we can enable CTRL+C delegation such that the parent
      process ignores the CTRL+C and instead delegates it to the
      child process.
  19. 26 Sep, 2016 1 commit
  20. 21 Sep, 2016 1 commit
    • Edward Z. Yang's avatar
      Don't solve for executables in legacy code path. · 9e99b3f4
      Edward Z. Yang authored
      There is a bug in `cabal configure`'s invocation of the solver in
              (SourcePackageDb mempty packagePrefs)
              [SpecificSourcePackage localPkg]
      We can see that the solver is given an EMPTY source package database.
      This is because we assume that everything you need from cabal configure
      is taken from the installed package index.
      But this is NOT true for executables, which never have an entry in the
      installed package index. So we SHOULD NOT solve for
      executables in the legacy codepath, since there isn't anything useful we
      can do with the info anyway.  This gets toggled using a new solver
      parameter SolveExecutables.
      I didn't bother with a test because this will be obsoleted by
      Fixes #3875
      Signed-off-by: default avatarEdward Z. Yang <>
  21. 10 Sep, 2016 1 commit
    • ttuegel's avatar
      Add `reconfigure` command · ae59bb3d
      ttuegel authored
      Fixes #2214 by adding a `reconfigure` command and invoking it whenever
      necessary. The last configure flags used are saved in a
      version-independent format so it should never be necessary for the user
      to reconfigure manually.
  22. 06 Sep, 2016 4 commits
  23. 21 Aug, 2016 2 commits
  24. 17 Aug, 2016 1 commit
  25. 25 Jul, 2016 2 commits
  26. 23 Jul, 2016 1 commit
  27. 21 Jul, 2016 2 commits
  28. 19 Jul, 2016 2 commits
    • Edward Z. Yang's avatar
      Make a copy of InstallPlan named SolverInstallPlan. · a0891eba
      Edward Z. Yang authored
      Now we copy-paste the contents of InstallPlan into SolverInstallPlan,
      thus giving it a separate set of types.  For now, we don't do anything
      else, e.g., remove unnecessary functions or specialize.
      We need a new function 'fromSolverInstallPlan' akin to
      'mapPreservingGraph' which can take an InstallPlan from the
      old solver install plan to the new one.
      Signed-off-by: default avatarEdward Z. Yang <>
    • Edward Z. Yang's avatar
      Move SolverInstallPlan to its own module. · 49d69a90
      Edward Z. Yang authored
      This is a preparatory commit for giving SolverInstallPlan
      its own type.  We first start by moving the type synonyms
      for SolverInstallPlan into their own module, and update
      module references to point to them.
      TODO: Maybe this module should go in the Solver hierarchy
      rather than the client hierarchy?
      Signed-off-by: default avatarEdward Z. Yang <>