1. 18 Feb, 2016 3 commits
    • Simon Peyton Jones's avatar
      (Another) minor refactoring of substitutions · b5292557
      Simon Peyton Jones authored
      No change in functionality here, but greater clarity:
      * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
        We are already maintaining an in-scope set in the fe_subst field,
        so it's silly do to it twice.
        (This isn't strictly connected to the rest of this patch, but
        the nomenclature changes below affect the same code, so I put
        them together.)
      * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
        out what to do, but in fact we almost always know which of the
        two we are doing.  So:
          - define extendTvSubst, extendCvSubst
          - and use them
      * Similar renamings in TyCoRep:
         - extendTCvSubstList        -->   extendTvSubstList
         - extendTCvSubstBinder      -->   extendTvSubstBinder
         - extendTCvSubstAndInScope  --> extendTvSubstAndInScope
      * Add Type.extendTvSubstWithClone, extendCvSubstWithClone
      * Similar nomenclature changes in Subst, SimplEnv, Specialise
      * Kill off TyCoRep.substTelescope (never used)
    • Simon Peyton Jones's avatar
      Fix desugaring of bang-pattern let-bindings · 01449eb5
      Simon Peyton Jones authored
      When implementing Strict Haskell, the patch 46a03fbe didn't faithfully
      implement the semantics given in the manual. In particular there was
      an ad-hoc case in mkSelectorBinds for "strict and no binders" that
      didn't work.
      This patch fixes it, curing Trac #11572.
      Howver it forced me to think about banged let-bindings, and I rather
      think we do not have quite the right semantics yet, so I've opened
      Trac #11601.
    • Ben Gamari's avatar
      Fix thinko that crept into D1908 · 27842ec1
      Ben Gamari authored
      RyanGlScott updated the Diff only after I had merged it.
  2. 17 Feb, 2016 13 commits
  3. 16 Feb, 2016 5 commits
    • Ben Gamari's avatar
      DynFlags: Don't panic on incompatible Safe Haskell flags · 2b906af0
      Ben Gamari authored
      We just return an arbitrary value since we are destined to fail due to
      the error anyways.
      Fixes #11580.
      Test Plan: Needs to be tested
      Reviewers: austin
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1925
      GHC Trac Issues: #11580
    • Yuras's avatar
      Suggest candidate instances in error message · 5fc06b97
      Yuras authored
      See Trac #9611. In "No instance..." error message we suggest instances
      for other types with the same occ name. It is usefull e.g. when we have
      two different versions of the same package installed.
      Test Plan: typecheck/should_fail/tcfail224
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1919
      GHC Trac Issues: #9611
    • Rik Steenkamp's avatar
      Fix typos · 49c5cb40
      Rik Steenkamp authored
      Reviewers: bgamari, austin
      Reviewed By: austin
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1915
    • Rik Steenkamp's avatar
      Fix two wrong uses of "data constructor" in error msgs · af5a0e50
      Rik Steenkamp authored
      Replace `NoDataKinds :: PromotionErr` by `NoDataKindsTC` and
      `NoDataKindsDC` (just like there is `NoTypeInTypeTC` and
      `NoTypeInTypeDC`). This allows for a correct error message when a kind
      signature contains a type constructor and `-XDataKinds` is not
      Apply a small fix to `TcError.hs` where instead of "data constructor" we
      should say "pattern synonym".
      Reviewers: austin, goldfire, bgamari
      Reviewed By: bgamari
      Subscribers: goldfire, thomie
      Differential Revision: https://phabricator.haskell.org/D1909
    • skvadrik's avatar
      Improved error message about exported type operators. · 693a54ea
      skvadrik authored
      There is ambiguty between (1) type constructors and (2) data
      constructors in export lists, e.g. '%%' can stand for both of them. This
      ambiguity is resolved in favor of (2).
      If the exported data constructor is not in scope, but type constructor
      with the same name is in scope, GHC should suggest adding 'type' keyword
      to resolve ambiguity in favor of (1) and enabling 'TypeOperators'
      The patch only extends the error message.
      See Trac #11432.
      Test Plan: `make test`
      Reviewers: simonpj, bgamari, austin
      Reviewed By: simonpj
      Subscribers: mpickering, thomie, goldfire, kosmikus
      Differential Revision: https://phabricator.haskell.org/D1902
      GHC Trac Issues: #11432
  4. 15 Feb, 2016 6 commits
  5. 14 Feb, 2016 1 commit
  6. 12 Feb, 2016 5 commits
  7. 11 Feb, 2016 6 commits
  8. 10 Feb, 2016 1 commit