1. 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
  2. 28 Sep, 2016 1 commit
  3. 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
  4. 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
  5. 13 Sep, 2016 2 commits
  6. 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
  7. 11 Sep, 2016 2 commits
    • Ryan Scott's avatar
      Fix derived Ix instances for one-constructor GADTs · 7b7ea8f4
      Ryan Scott authored
      Summary:
      Standalone-derived `Ix` instances would panic on GADTs with exactly
      one constructor, since the list of fields was being passed to a function that
      uses `foldl1` in order to generate an implementation for `inRange`. This adds a
      simple check that makes `inRange` be `True` whenever a product type has no
      fields.
      
      Fixes #12583.
      
      Test Plan: make test TEST=12583
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2521
      
      GHC Trac Issues: #12583
      7b7ea8f4
    • Matthew Pickering's avatar
      Remove uses of mkMatchGroupName · 04184a2a
      Matthew Pickering authored
      You can now just use `mkMatchGroup`.
      04184a2a
  8. 05 Sep, 2016 3 commits
  9. 02 Sep, 2016 1 commit
  10. 31 Aug, 2016 1 commit
  11. 30 Aug, 2016 1 commit
  12. 29 Aug, 2016 1 commit
    • Ryan Scott's avatar
      Remove unused DerivInst constructor for DerivStuff · f4384ef5
      Ryan Scott authored
      Summary:
      Back when derived `Generic` instances used to generate auxiliary datatypes,
      they would also generate instances for those datatypes. Nowadays, GHC generics
      uses a `DataKinds`-based encoding that requires neither auxiliary datatypes
      (corresponding to the `DerivTyCon` constructor of `DerivStuff`) nor instances
      for them (the `DerivInst` constructor of `DerivStuff`). It appears that
      `DerivTyCon` constructor was removed at some point, but `DerivInst` never was.
      
      No `DerivInst` values are ever constructed, so we can safely remove it.
      
      Test Plan: It builds
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2481
      f4384ef5
  13. 26 Aug, 2016 2 commits
  14. 23 Aug, 2016 1 commit
    • Ryan Scott's avatar
      Template Haskell support for unboxed sums · 613d7455
      Ryan Scott authored
      This adds new constructors `UnboxedSumE`, `UnboxedSumT`, and
      `UnboxedSumP` to represent unboxed sums in Template Haskell.
      
      One thing you can't currently do is, e.g., `reify ''(#||#)`, since I
      don't believe unboxed sum type/data constructors can be written in
      prefix form.  I will look at fixing that as part of #12514.
      
      Fixes #12478.
      
      Test Plan: make test TEST=T12478_{1,2,3}
      
      Reviewers: osa1, goldfire, austin, bgamari
      
      Reviewed By: goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2448
      
      GHC Trac Issues: #12478
      613d7455
  15. 21 Aug, 2016 4 commits
  16. 17 Aug, 2016 3 commits
  17. 16 Aug, 2016 1 commit
  18. 14 Aug, 2016 1 commit
  19. 05 Aug, 2016 1 commit
  20. 01 Aug, 2016 1 commit
  21. 26 Jul, 2016 1 commit
    • Edward Z. Yang's avatar
      Compute boot-defined TyCon names from ModIface. · 8f63ba30
      Edward Z. Yang authored
      Summary:
      Three things in this commit:
      
          1. Get rid of sb_ids; we are not going to use them
          to avoid infinite unfoldings in hs-boot files.
      
          2. Compute sb_tcs from ModIface rather than ModDetails.
          This means that the typechecker can look at this field
          without forcing the boot ModDetails, which would be
          bad if the ModDetails is not available yet (due to
          knot tying.)
      
          3. A big honking comment explaining what is going on
          here.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2380
      8f63ba30
  22. 25 Jul, 2016 1 commit
  23. 21 Jul, 2016 1 commit
    • Ömer Sinan Ağacan's avatar
      Implement unboxed sum primitive type · 714bebff
      Ömer Sinan Ağacan authored
      Summary:
      This patch implements primitive unboxed sum types, as described in
      https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes.
      
      Main changes are:
      
      - Add new syntax for unboxed sums types, terms and patterns. Hidden
        behind `-XUnboxedSums`.
      
      - Add unlifted unboxed sum type constructors and data constructors,
        extend type and pattern checkers and desugarer.
      
      - Add new RuntimeRep for unboxed sums.
      
      - Extend unarise pass to translate unboxed sums to unboxed tuples right
        before code generation.
      
      - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better
        code generation when sum values are involved.
      
      - Add user manual section for unboxed sums.
      
      Some other changes:
      
      - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to
        `MultiValAlt` to be able to use those with both sums and tuples.
      
      - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really
        wrong, given an `Any` `TyCon`, there's no way to tell what its kind
        is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`.
      
      - Fix some bugs on the way: #12375.
      
      Not included in this patch:
      
      - Update Haddock for new the new unboxed sum syntax.
      
      - `TemplateHaskell` support is left as future work.
      
      For reviewers:
      
      - Front-end code is mostly trivial and adapted from unboxed tuple code
        for type checking, pattern checking, renaming, desugaring etc.
      
      - Main translation routines are in `RepType` and `UnariseStg`.
        Documentation in `UnariseStg` should be enough for understanding
        what's going on.
      
      Credits:
      
      - Johan Tibell wrote the initial front-end and interface file
        extensions.
      
      - Simon Peyton Jones reviewed this patch many times, wrote some code,
        and helped with debugging.
      
      Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin,
                 simonmar, hvr, erikd
      
      Reviewed By: simonpj
      
      Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire,
                   thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2259
      714bebff
  24. 20 Jul, 2016 3 commits
    • Ben Gamari's avatar
      Revert "Clean up interaction between name cache and built-in syntax" · 83e4f495
      Ben Gamari authored
      This reverts commit 9513fe6b.
      
      Sadly this broke with -DDEBUG.
      83e4f495
    • Ben Gamari's avatar
      Clean up interaction between name cache and built-in syntax · 9513fe6b
      Ben Gamari authored
      This cleans up various aspects of the handling of built-in syntax in the
      original name cache (hopefully resulting in a nice reduction in compiler
      allocations),
      
        * Remove tuple types from original name cache: There is really no
          reason for these to be in the name cache since we already handle
          them specially in interface files to ensure that we can resolve them
          directly to Names, avoiding extraneous name cache lookups.
      
        * Sadly it's not possible to remove all traces of tuples from the
          name cache, however. Namely we need to keep the tuple type
          representations in since otherwise they would need to be wired-in
      
        * Remove the special cases for (:), [], and (##) in isBuiltInOcc_maybe
          and rename it to isTupleOcc_maybe
      
        * Split lookupOrigNameCache into two variants,
      
           * lookupOrigNameCache': Merely looks up an OccName in the original
             name cache, making no attempt to resolve tuples
      
           * lookupOrigNameCache: Like the above but handles tuples as well.
             This is given the un-primed name since it does the "obvious"
             thing from the perspective of an API user, who knows nothing of
             our special treatment of tuples.
      
      Arriving at this design took a significant amount of iteration. The
      trail of debris leading here can be found in #11357.
      
      Thanks to ezyang and Simon for all of their help in coming to this
      solution.
      
      Test Plan: Validate
      
      Reviewers: goldfire, simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D2414
      
      GHC Trac Issues: #11357
      9513fe6b
    • Ben Gamari's avatar
      TcInteract: Add braces to matchClassInst trace output · 908f8e23
      Ben Gamari authored
      This allows you to easily move to the result in a well-equipped editor.
      908f8e23