This project is mirrored from Pull mirroring updated .
  1. 19 Dec, 2017 9 commits
  2. 18 Dec, 2017 1 commit
  3. 17 Dec, 2017 8 commits
    • Herbert Valerio Riedel's avatar
      Test for new defaulting-logic · 37230a6a
      Herbert Valerio Riedel authored
      This tweaks the existing `CustomPlain` test to test the legacy
      defaulting logic for the unconditionally `Custom` default.
      Morever, a new `SimpleDefault` test has been added which tests
      that `cabal-version:2.1` does indeed infer `build-type: Simple`
      when there is no `custom-setup` stanza defined.
    • Herbert Valerio Riedel's avatar
      changelog entry for #4958 · 295793e4
      Herbert Valerio Riedel authored
    • Herbert Valerio Riedel's avatar
      Implement better defaulting for `build-type` · 9fb03d73
      Herbert Valerio Riedel authored
      This implements the following defaulting rules:
       * For `cabal-version:2.0` and below, default to the `Custom`
         build-type unconditionally (legacy defaulting)
       * Otherwise, if a `custom-setup` stanza is defined, default to
         the `Custom` build-type; else default to `Simple` build-type.
      This gets us better defaults for the two most popular use-cases, and
      which can be statically inferred by only looking at the `.cabal` file.
      This allows us to bring down the minimal (modern) trivial cabal
      package definition down to a single file with 4 lines:
          cabal-version: 2.1
          name: mu
          version: 0
      NB: We don't need any `Setup.hs` file, as `cabal sdist` will magically
      generate one on the fly.
    • kristenk's avatar
      Solver: Combine dependencies on the same package in the same 'build-depends'. · 4f7ac10d
      kristenk authored
      This commit is unlikely to have an effect on real packages, but it reduces the
      chance of performance problems caused by duplicate dependencies in the solver
      quickcheck tests.  It also adds a regression test to memory-usage-tests.
    • kristenk's avatar
      Call simplifyVersionRange in solver convenience functions (.||.) and (.&&.). · 5270950f
      kristenk authored
      It is probably better to simplify version ranges in most cases in the solver, in
      order to simplify error messages and save memory.  Currently, (.||.) is used once
      for lifting dependencies out of conditionals, and (.&&.) isn't used.
    • kristenk's avatar
      Solver: Remove redundant flag choices from FlaggedDeps. · d239a60f
      kristenk authored
      This commit simplifies the solver's internal representation of package
      conditionals by removing branches that are unreachable.  For example, the solver
      now simplifies
      if flag(A)
        if flag(A)
          build-depends: package-a
          build-depends: package-b
      if flag(A)
        build-depends: package-a
      because A must be true for the second conditional to be relevant to the
      finalized PackageDescription.
      This change probably won't improve performance by simplifying real packages.
      However, it fixes a bug in the solver's handling of a certain edge case.  Before
      this change, it was possible for the solver to create DependencyReasons with
      conflicting flag values.  The conflicting values could cause a problem when
      one was FlagBoth, the value used when the same dependency appears on both sides
      of a conditional.  Here is an example:
      if flag(A)
        if flag(A)
          build-depends: unknown-package
          build-depends: unknown-package
      Previously, the solver inserted both A=FlagTrue and A=FlagBoth into the
      DependencyReason for the dependency on unknown-package. When the previous
      commit changed the association list of flag values into a map, FlagBoth replaced
      FlagTrue and prevented the solver from trying -A.
      This commit simplifies the conditionals to:
      if flag(A)
        build-depends: unknown-package
      It also adds some unit tests for dependencies occurring on both sides of
      conditionals. "testBackjumpingWithCommonDependency" tests the example above.
    • kristenk's avatar
      Solver: Deduplicate flags and stanzas in DependencyReason. · 6fe3c5f7
      kristenk authored
      This commit changes DependencyReason's list fields to maps and sets. Duplicate
      flags were possible when a flag appeared multiple times in nested conditionals
      or a flag controlled a "Buildable: False" field. The duplicate flag could show
      up in log messages:
      [__5] trying: json-rpc-client:+demo
      [__6] trying: process- (dependency of json-rpc-client +demo +demo)
      [__5] trying: json-rpc-client:+demo
      [__6] trying: process- (dependency of json-rpc-client +demo)
    • Herbert Valerio Riedel's avatar
  4. 16 Dec, 2017 2 commits
  5. 13 Dec, 2017 1 commit
  6. 12 Dec, 2017 4 commits
    • Oleg Grenrus's avatar
      Common stanzas · bfb1967c
      Oleg Grenrus authored
      - common stanzas can be include other common stanzas
      - `import: name1, name2` to import multiple stanzas
      - Parse common stanzas in the same pass with other sections.
      - Common stanzas have to be defined before use.
      - Also negative tests
      - Terse documentation, let's improve it as questions are asked
      - Edit gen-extra-source-files to include golden files
      - Amend elif warning to mention cabal-version: 2.2
      - In regression golden tests, include also warnings
      Note: ATM the common stanzas are completely handled inside parser,
      GenericPackageDescription doesn't know about them anymore.
      That can be changed, but the the flattening of
      GenericPackageDescription to PackageDescription may fail.
      I don't want to do that refactor now.
    • Mikhail Glushenkov's avatar
      Formatting. · f0d688a9
      Mikhail Glushenkov authored
      [ci skip]
    • Mikhail Glushenkov's avatar
      Temporarily pin pretty-show to 1.6.13. · e80e1a11
      Mikhail Glushenkov authored
      Should unbork the test suite.
    • George Wilson's avatar
      Fix NondecreasingIndentation filtering · 3f497f2c
      George Wilson authored
      Not every supported extension for a compiler has a corresponding flag.
      for example NondecreasingIndentation is enabled by default on GHC 7.0.4,
      hence it is considered a supported extension but not an accepted flag.
      To resolve this, wrap Flags in Maybe, and follow through the resulting
      Fixes #4443
  7. 11 Dec, 2017 4 commits
  8. 10 Dec, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Clarify documentation regarding ^>= operator · 4abf81f8
      Herbert Valerio Riedel authored
      This represents an incremental improvement over the current state.
      However, there's more work to be done in terms of restructuring/reordering
      to present the information in an easier to digest as well as apply the new
      facilities effectively. This future work will be tracked in #4944.
      [skip ci]
  9. 07 Dec, 2017 2 commits
  10. 06 Dec, 2017 4 commits
  11. 05 Dec, 2017 1 commit
  12. 04 Dec, 2017 3 commits