1. 05 Apr, 2019 2 commits
  2. 04 Apr, 2019 3 commits
    • Ryan Scott's avatar
      Use funPrec, not topPrec, to parenthesize GADT argument types · 51fd3571
      Ryan Scott authored
      A simple oversight. Fixes #16527.
      51fd3571
    • Ryan Scott's avatar
      Fix #16518 with some more kind-splitting smarts · 25c02ea1
      Ryan Scott authored
      This patch corrects two simple oversights that led to #16518:
      
      1. `HsUtils.typeToLHsType` was taking visibility into account in the
         `TyConApp` case, but not the `AppTy` case. I've factored out the
         visibility-related logic into its own `go_app` function and now
         invoke `go_app` from both the `TyConApp` and `AppTy` cases.
      2. `Type.fun_kind_arg_flags` did not properly split kinds with
         nested `forall`s, such as
         `(forall k. k -> Type) -> (forall k. k -> Type)`. This was simply
         because `fun_kind_arg_flags`'s `FunTy` case always bailed out and
         assumed all subsequent arguments were `Required`, which clearly
         isn't the case for nested `forall`s. I tweaked the `FunTy` case
         to recur on the result kind.
      25c02ea1
    • Yuriy Syrovetskiy's avatar
  3. 03 Apr, 2019 12 commits
    • Ben Gamari's avatar
      gitlab: Fix label names in issue templates · 895394c2
      Ben Gamari authored
      895394c2
    • Ben Gamari's avatar
      gitlab-ci: Build hyperlinked sources for releases · 6f13e7b1
      Ben Gamari authored
      Fixes #16445.
      6f13e7b1
    • Sebastian Graf's avatar
      Fix Uncovered set of literal patterns · 4626cf21
      Sebastian Graf authored
      Issues #16289 and #15713 are proof that the pattern match checker did
      an unsound job of estimating the value set abstraction corresponding to
      the uncovered set.
      
      The reason is that the fix from #11303 introducing `NLit` was
      incomplete: The `LitCon` case desugared to `Var` rather than `LitVar`,
      which would have done the necessary case splitting analogous to the
      `ConVar` case.
      
      This patch rectifies that by introducing the fresh unification variable
      in `LitCon` in value abstraction position rather than pattern postition,
      recording a constraint equating it to the constructor expression rather
      than the literal. Fixes #16289 and #15713.
      4626cf21
    • Ben Gamari's avatar
      configure: Always use AC_LINK_ELSEIF when testing against assembler · 7b090b53
      Ben Gamari authored
      This fixes #16440, where the build system incorrectly concluded that the
      `.subsections_via_symbols` assembler directive was supported on a Linux
      system. This was caused by the fact that gcc was invoked with `-flto`;
      when so-configured gcc does not call the assembler but rather simply
      serialises its AST for compilation during the final link.
      
      This is described in Note [autoconf assembler checks and -flto].
      7b090b53
    • Chris Martin's avatar
      Inline the definition of 'ap' in the Monad laws · bf6dbe3d
      Chris Martin authored
      The law as it is currently written is meaningless, because nowhere have
      we defined the implementation of 'ap'. The reader of the Control.Monad
      documentation is provided with only a type signature,
      
      > ap :: Monad m => m (a -> b) -> m a -> m b
      
      an informal description,
      
      > In many situations, the liftM operations can be replaced by uses of
      > ap, which promotes function application.
      
      and a relationship between 'ap' and the 'liftM' functions
      
      > return f `ap` x1 `ap` ... `ap` xn
      > is equivalent to
      > liftMn f x1 x2 ... xn
      
      Without knowing how 'ap' is defined, a law involving 'ap' cannot
      provide any guidance for how to write a lawful Monad instance, nor can
      we conclude anything from the law.
      
      I suspect that a reader equipped with the understanding that 'ap' was
      defined prior to the invention of the Applicative class could deduce
      that 'ap' must be defined in terms of (>>=), but nowhere as far as I can
      tell have we written this down explicitly for readers without the
      benefit of historical context.
      
      If the law is meant to express a relationship among (<*>), (>>=), and
      'return', it seems that it is better off making this statement directly,
      sidestepping 'ap' altogether.
      bf6dbe3d
    • Chris Martin's avatar
      Correct two misspellings of "separately" · 722fdddf
      Chris Martin authored
      722fdddf
    • Ben Gamari's avatar
      dd3a3d08
    • Ben Gamari's avatar
      3364def0
    • Frank Steffahn's avatar
      733f1b52
    • Andrew Martin's avatar
    • Nathan Collins's avatar
      users-guide: Fix typo · 2ec749b5
      Nathan Collins authored
      2ec749b5
    • Andreas Klebinger's avatar
      Fix faulty substitutions in StgCse (#11532). · 5a75ccd0
      Andreas Klebinger authored
      `substBndr` should rename bindings which shadow existing ids.
      However while it was renaming the bindings it was not adding proper substitutions
      for renamed bindings.
      Instead of adding a substitution of the form `old -> new` for renamed
      bindings it mistakenly added `old -> old` if no replacement had taken
      place while adding none if `old` had been renamed.
      
      As a byproduct this should improve performance, as we no longer add
      useless substitutions for unshadowed bindings.
      5a75ccd0
  4. 02 Apr, 2019 7 commits
  5. 01 Apr, 2019 11 commits
  6. 30 Mar, 2019 1 commit
  7. 29 Mar, 2019 4 commits
    • Ben Gamari's avatar
      Bump transformers to 0.5.6.2 · 6e15ca54
      Ben Gamari authored
      See #16199.
      6e15ca54
    • Ben Gamari's avatar
      ci: Check that changelogs don't contain "TBA" · 1a567133
      Ben Gamari authored
      This ensures that the release dates in the library changelogs are
      properly set.
      1a567133
    • Artem Pelenitsyn's avatar
    • Michael Peyton Jones's avatar
      Visibility: handle multiple units with the same name · 8a20bfc2
      Michael Peyton Jones authored
      Fixes #16228. The included test case is adapted from the reproduction in
      the issue, and fails without this patch.
      
      ------
      
      We compute an initial visilibity mapping for units based on what is
      present in the package databases. To seed this, we compute a set of all
      the package configs to add visibilities for.
      
      However, this set was keyed off the unit's *package name*. This is
      correct, since we compare packages across databases by version. However,
      we would only ever consider a single, most-preferable unit from the
      database in which it was found.
      
      The effect of this was that only one of the libraries in a Cabal package
      would be added to this initial set. This would cause attempts to use
      modules from the omitted libraries to fail, claiming that the package
      was hidden (even though `ghc-pkg` would correctly show it as visible).
      
      A solution is to do the selection of the most preferable packages
      separately, and then be sure to consider exposing all units in the
      same package in the same package db. We can do this by picking a
      most-preferable unit for each package name, and then considering
      exposing all units that are equi-preferable with that unit.
      
      ------
      
      Why wasn't this bug apparent to all people trying to use sub-libraries
      in Cabal? The answer is that Cabal explicitly passes `-package` and
      `-package-id` flags for all the packages it wants to use, rather than
      relying on the state of the package database. So this bug only really
      affects people who are trying to use package databases produced by Cabal
      outside of Cabal itself.
      
      One particular example of this is the way that the
      Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these
      are equipped with a package database containing all the needed
      package dependencies, and the user is not expected to pass
      `-package` flags explicitly.
      8a20bfc2