1. 17 Oct, 2016 3 commits
  2. 15 Oct, 2016 2 commits
  3. 14 Oct, 2016 2 commits
    • Ryan Scott's avatar
      Make error when deriving an instance for a typeclass less misleading · d5a4e49d
      Ryan Scott authored
      Before, when you attempted to derive an instance for a typeclass,
      e.g.,
      
      ```
      class C1 (a :: Constraint) where
      class C2 where
      
      deriving instance C1 C2
      ```
      
      GHC would complain that `C2`'s data constructors aren't in scope. But
      that
      makes no sense, since typeclasses don't have constructors! By refining
      the
      checks that GHC performs when deriving, we can make the error message a
      little more sensible.
      
      This also cleans up a related `DeriveAnyClass` infelicity. Before, you
      wouldn't have been able to compile code like this:
      
      ```
      import System.IO (Handle)
      class C a
      deriving instance C Handle
      ```
      
      Since GHC was requiring that all data constructors of `Handle` be in
      scope. But `DeriveAnyClass` doesn't even generate code that mentions
      any data constructors, so this requirement is silly!
      
      Fixes #11509.
      
      Test Plan: make test TEST=T11509
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2558
      
      GHC Trac Issues: #11509
      d5a4e49d
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  4. 13 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Further improve error handling in TcRn monad · 2fdf21bf
      Simon Peyton Jones authored
      This patch builds on the one for Trac #12124, by dealing properly
      with out-of-scope "hole" errors.
      
      This fixes Trac #12529. The hard error coming from visible type application
      is still there, but the out-of-scope error is no longer suppressed.
      
      (Arguably the VTA message should be suppressed somehow, but that's a
      battle for another day.)
      2fdf21bf
  5. 12 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Add derived shadows only for Wanted constraints · 8fa5f5b1
      Simon Peyton Jones authored
      This patch implements choice (3) of comment:14 on Trac #12660.
      It cures an infinite loop (caused by the creation of an infinite
      type) in in compiling the 'singletons' package.
      
      See Note [Add derived shadows only for Wanteds] in TcSMonad.
      8fa5f5b1
  6. 10 Oct, 2016 4 commits
    • Simon Peyton Jones's avatar
      Move zonking out of tcFamTyPats · 76a5477b
      Simon Peyton Jones authored
      In tcFamTyPats we were zonking from the TcType world to the
      Type world, ready to build the results into a CoAxiom (which
      should have no TcType stuff.  But the 'thing_inside' for
      tcFamTyPats also must be zonked, and that zonking must have
      the ZonkEnv from the binders zonked tcFamTyPats.
      
      Ugh.  This caused an assertion failure (with DEBUG on) in
      RaeBlobPost and TypeLevelVec, both in tests/dependent, as
      shown in Trac #12682.  Why it hasn't shown up before now
      is obscure to me.
      
      So I moved the zonking stuff out of tcFamTyPats to its
      three call sites, where we can do it all together. Very
      slightly longer, but much more robust.
      76a5477b
    • Simon Peyton Jones's avatar
      Delete orphan where clause · 88eb7738
      Simon Peyton Jones authored
      88eb7738
    • Simon Peyton Jones's avatar
      Rename a parameter; trivial refactor · b5c89636
      Simon Peyton Jones authored
      b5c89636
    • Simon Peyton Jones's avatar
      Orient improvement constraints better · b255ae7b
      Simon Peyton Jones authored
      This patch fixes an infinite loop in the constraint solver,
      shown up by Trac #12522.
      
      The solution is /very/ simple: just reverse the orientation of the
      derived constraints arising from improvement using type-family
      injectivity.  I'm not very proud of the fix --- it seems fragile
      --- but it has the very great merit of simplicity, and it works
      fine.
      
      See Note [Improvement orientation] in TcInteract, and some
      discussion on the Trac ticket.
      b255ae7b
  7. 08 Oct, 2016 4 commits
  8. 06 Oct, 2016 2 commits
    • Joachim Breitner's avatar
      Remove dead code “mkHsConApp” · 57a207ca
      Joachim Breitner authored
      Differential Revision: https://phabricator.haskell.org/D2574
      57a207ca
    • Ryan Scott's avatar
      Refactor TcDeriv and TcGenDeriv · 4a03012a
      Ryan Scott authored
      Summary:
      Keeping a promise I made to Simon to clean up these modules.
      
      This change splits up the massive `TcDeriv` and `TcGenDeriv` modules into
      somewhat more manageable pieces. The new modules are:
      
      * `TcGenFunctor`: This contains the deriving machinery for `Functor`,
        `Foldable`, and `Traversable` (which all use the same underlying algorithm).
      * `TcDerivInfer`: This is the new home for `inferConstraints`,
        `simplifyInstanceContexts`, and related functions, whose role is to come up
        with the derived instance context and subsequently simplify it.
      * `TcDerivUtils`: This is a grab-bag module that contains several
        error-checking utilities originally in `TcDeriv`, as well as some functions
        that `TcDeriv` and `TcDerivInfer` both need.
      
      The end result is that `TcDeriv` is now less than 1,600 SLOC (originally 2,686
      SLOC), and `TcGenDeriv` is now about 2,000 SLOC (originally 2,964).
      
      In addition, this also implements a couple of tiny refactorings:
      
      * I transformed `type Condition = (DynFlags, TyCon) -> Validity` into
        `type Condition = DynFlags -> TyCon -> Validity`
      * I killed the `DerivSpecGeneric` constructor for `DerivSpecMechanism`, and
        merged its functionality into `DerivSpecStock`. In addition,
        `hasStockDeriving` now contains key-value pairs for `Generic` and `Generic1`,
        so they're no longer treated as an awkward special case in `TcDeriv`.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2568
      4a03012a
  9. 05 Oct, 2016 2 commits
  10. 02 Oct, 2016 1 commit
  11. 01 Oct, 2016 1 commit
    • Ryan Scott's avatar
      Implement deriving strategies · 9e862765
      Ryan Scott authored
      Allows users to explicitly request which approach to `deriving` to use
      via keywords, e.g.,
      
      ```
      newtype Foo = Foo Bar
        deriving Eq
        deriving stock    Ord
        deriving newtype Show
      ```
      
      Fixes #10598. Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, kosmikus, goldfire, alanz, bgamari, simonpj, austin,
      erikd, simonmar
      
      Reviewed By: alanz, bgamari, simonpj
      
      Subscribers: thomie, mpickering, oerjan
      
      Differential Revision: https://phabricator.haskell.org/D2280
      
      GHC Trac Issues: #10598
      9e862765
  12. 30 Sep, 2016 4 commits
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      
      Cure.
      
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
      b612da66
    • Simon Peyton Jones's avatar
      Add Outputable Report in TcErrors · 3012c431
      Simon Peyton Jones authored
      ...just for debug output
      3012c431
    • Simon Peyton Jones's avatar
      Fix a bug in occurs checking · 66a8c194
      Simon Peyton Jones authored
      1. Trac #12593 exposed a long-standing bug in the occurs
         checking machinery.  When unifying two type variables
                a ~ b
         where a /= b, we were assuming that there could be
         no occurs-check error.  But there can: 'a' can occur
         in b's kind!  When the RHS was a non-tyvar we used
         occurCheckExpand, which /did/ look in kinds, but not
         when the RHS was a tyvar.
      
         This bug has been lurking ever since TypeInType, maybe
         longer.  And it was present both in TcUnify (the on-the-fly
         unifier), and in TcInteract.
      
         I ended up refactoring both so that the tyvar/tyvar
         path naturally goes through the same occurs-check as
         non-tyvar rhss.  It's simpler and more robust now.
      
         One good thing is that both unifiers now share
             TcType.swapOverVars
             TcType.canSolveByUnification
         previously they had different logic for the same goals
      
      2. Fixing this bug exposed another!  In T11635 we end
         up unifying
         (alpha :: forall k. k->*) ~ (beta :: forall k. k->*)
         Now that the occurs check is done for tyvars too, we
         look inside beta's kind.  And then reject the program
         becuase of the forall inside there.  But in fact that
         forall is fine -- it does not count as impredicative
         polymoprhism.   See Note [Checking for foralls]
         in TcType.
      
      3. All this fuss around occurrence checking forced me
         to look at TcUnify.checkTauTvUpdate
                and TcType.occurCheckExpand
         There's a lot of duplication there, and I managed
         to elminate quite a bit of it. For example,
         checkTauTvUpdate called a local 'defer_me'; and then
         called occurCheckExpand, which then used a very
         similar 'fast_check'.
      
         Things are better, but there is more to do.
      66a8c194
    • Simon Peyton Jones's avatar
      A bit of tracing about flattening · 0b533a25
      Simon Peyton Jones authored
      0b533a25
  13. 28 Sep, 2016 1 commit
  14. 23 Sep, 2016 1 commit
    • Richard Eisenberg's avatar
      Fix #12442. · 9766b0c8
      Richard Eisenberg authored
      The problem is described in the ticket.
      
      This patch adds new variants of the access points to the pure
      unifier that allow unification of types only when the caller
      wants this behavior. (The unifier used to also unify kinds.)
      This behavior is appropriate when the kinds are either already
      known to be the same, or the list of types provided are a
      list of well-typed arguments to some type constructor. In the
      latter case, unifying earlier types in the list will unify the
      kinds of any later (dependent) types.
      
      At use sites, I went through and chose the unification function
      according to the criteria above.
      
      This patch includes some modest performance improvements as we
      are now doing less work.
      9766b0c8
  15. 15 Sep, 2016 1 commit
    • Ben Gamari's avatar
      Unify CallStack handling in ghc · 626db8f8
      Ben Gamari authored
      Here we introduce compatibility wrappers for HasCallStack constraints.
      This is necessary as we must support GHC 7.10.1 which lacks sane call
      stack support. We also introduce another constraint synonym,
      HasDebugCallStack, which only provides a call stack when DEBUG is set.
      626db8f8
  16. 13 Sep, 2016 2 commits
  17. 12 Sep, 2016 2 commits
    • Simon Peyton Jones's avatar
      Remove unused exports · 21d0bfe1
      Simon Peyton Jones authored
      21d0bfe1
    • Simon Peyton Jones's avatar
      Be less picky about reporing inaccessible code · 03541cba
      Simon Peyton Jones authored
      Triggered by the discussion on Trac #12466, this patch
      makes GHC less aggressive about reporting an error when
      there are insoluble Givens.
      
      Being so agressive was making some libraries fail to
      compile, and is arguably wrong in at least some cases.
      See the discussion on the ticket.
      
      Several test now pass when they failed before; see
      the files-modified list for this patch.
      03541cba
  18. 11 Sep, 2016 2 commits
  19. 05 Sep, 2016 3 commits
  20. 02 Sep, 2016 1 commit