1. 25 Feb, 2016 1 commit
    • Georgios Karachalias's avatar
      (Alternative way to) address #8710 · 67393977
      Georgios Karachalias authored and Ben Gamari's avatar Ben Gamari committed
      Issue a separate warning per redundant (or inaccessible) clause.
      This way each warning can have more precice location information
      (the location of the clause under consideration and not the whole
      match).
      
      I thought that this could be too much but actually the number of
      such warnings is bound by the number of cases matched against (in
      contrast to the non-exhaustive warnings which may be exponentially
      more).
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1920
      
      GHC Trac Issues: #8710
      67393977
  2. 23 Feb, 2016 2 commits
  3. 18 Feb, 2016 2 commits
    • Ben Gamari's avatar
      Unwire Typeable representation types · 206a8bf4
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      In order to make this work I needed to shuffle around typechecking a bit
      such that `TyCon` and friends are available during compilation of
      GHC.Types.  I also did a bit of refactoring of `TcTypeable`.
      
      Test Plan: Validate
      
      Reviewers: simonpj, austin
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1906
      
      GHC Trac Issues: #11120
      206a8bf4
    • 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.
      01449eb5
  4. 17 Feb, 2016 1 commit
  5. 12 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Simplify AbsBinds wrapping · c6485d5e
      Simon Peyton Jones authored
      In poking Trac #11414 I found myself sinking into the abe_inst_wrap
      swamp.  What is this strange thing?  (It turned out that #11414 was
      breaking because of it.)
      
      Thrillingly, I found a way to sweep it away again, putting the deep
      instantation into tcMonoBinds instead of mkExport; and it turned out
      that the fun_co_fn field of FunBind was already there ready to receive
      exactly this wrapper. Hooray.  Result
      
      * Death to abe_inst_wrap
      * Death to mbi_orig
      * Death to the plumbing in tcPolyInfer that did the
        deep instantiation
      
      I did find that I had to re-engineer the treatment of instance type
      signatures (again), but the result looks more modular and robust to
      me.
      
      And #11414 is fixed.
      c6485d5e
  6. 27 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
  7. 18 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactoring on IdInfo and system derived names · ec8a188a
      Simon Peyton Jones authored
      Some modest refactoring, triggered in part by Trac #11051
      
      * Kill off PatSynId, ReflectionId in IdDetails
        They were barely used, and only for pretty-printing
      
      * Add helper function Id.mkExportedVanillaId, and use it
      
      * Polish up OccName.isDerivedOccName, as a predicate for
        definitions generated internally by GHC, which we
        might not want to show to the user.
      
      * Kill off unused OccName.mkDerivedTyConOcc
      
      * Shorten the derived OccNames for newtype and data
        instance axioms
      
      * A bit of related refactoring around newFamInstAxiomName
      ec8a188a
  8. 17 Jan, 2016 1 commit
  9. 07 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Make demand analysis understand catch · 9915b656
      Simon Peyton Jones authored
      As Trac #11222, and #10712 note, the strictness analyser
      needs to be rather careful about exceptions.  Previously
      it treated them as identical to divergence, but that
      won't quite do.
      
      See Note [Exceptions and strictness] in Demand, which
      explains the deal.
      
      Getting more strictness in 'catch' and friends is a
      very good thing.  Here is the nofib summary, keeping
      only the big ones.
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                fasta          -0.1%     -6.9%     -3.0%     -3.0%     +0.0%
                  hpg          -0.1%     -2.0%     -6.2%     -6.2%     +0.0%
             maillist          -0.1%     -0.3%      0.08      0.09     +1.2%
      reverse-complem          -0.1%    -10.9%     -6.0%     -5.9%     +0.0%
               sphere          -0.1%     -4.3%      0.08      0.08     +0.0%
                 x2n1          -0.1%     -0.0%      0.00      0.00     +0.0%
      --------------------------------------------------------------------------------
                  Min          -0.2%    -10.9%    -17.4%    -17.3%     +0.0%
                  Max          -0.0%     +0.0%     +4.3%     +4.4%     +1.2%
       Geometric Mean          -0.1%     -0.3%     -2.9%     -3.0%     +0.0%
      
      On the way I did quite a bit of refactoring in Demand.hs
      9915b656
  10. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
  11. 23 Dec, 2015 1 commit
  12. 17 Dec, 2015 1 commit
  13. 15 Dec, 2015 2 commits
  14. 14 Dec, 2015 1 commit
  15. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  16. 03 Dec, 2015 1 commit
    • Georgios Karachalias's avatar
      Major Overhaul of Pattern Match Checking (Fixes #595) · 8a506104
      Georgios Karachalias authored
      This patch adresses several problems concerned with exhaustiveness and
      redundancy checking of pattern matching. The list of improvements includes:
      
      * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.).
        This fixes #4139, #3927, #8970 and other related tickets.
      
      * Making the check laziness-aware. Cases that are overlapped but affect
        evaluation are issued now with "Patterns have inaccessible right hand side".
        Additionally, "Patterns are overlapped" is now replaced by "Patterns are
        redundant".
      
      * Improved messages for literals. This addresses tickets #5724, #2204, etc.
      
      * Improved reasoning concerning cases where simple and overloaded
        patterns are matched (See #322).
      
      * Substantially improved reasoning for pattern guards. Addresses #3078.
      
      * OverloadedLists extension does not break exhaustiveness checking anymore
        (addresses #9951). Note that in general this cannot be handled but if we know
        that an argument has type '[a]', we treat it as a list since, the instance of
        'IsList' gives the identity for both 'fromList' and 'toList'. If the type is
        not clear or is not the list type, then the check cannot do much still. I am
        a bit concerned about OverlappingInstances though, since one may override the
        '[a]' instance with e.g. an '[Int]' instance that is not the identity.
      
      * Improved reasoning for nested pattern matching (partial solution). Now we
        propagate type and (some) term constraints deeper when checking, so we can
        detect more inconsistencies. For example, this is needed for #4139.
      
      I am still not satisfied with several things but I would like to address at
      least the following before the next release:
          Term constraints are too many and not printed for non-exhaustive matches
      (with the exception of literals). This sometimes results in two identical (in
      appearance) uncovered warnings. Unless we actually show their difference, I
      would like to have a single warning.
      8a506104
  17. 22 Nov, 2015 1 commit
  18. 14 Nov, 2015 1 commit
  19. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  20. 29 Oct, 2015 2 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
  21. 15 Oct, 2015 1 commit
  22. 02 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Fix treatment of -0.0 · eb975d2e
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      Here we fix a few mis-optimizations that could occur in code with
      floating point comparisons with -0.0. These issues arose from our
      insistence on rewriting equalities into case analyses and the
      simplifier's ignorance of floating-point semantics.
      
      For instance, in Trac #10215 (and the similar issue Trac #9238) we
      turned `ds == 0.0` into a case analysis,
      
      ```
      case ds of
          __DEFAULT -> ...
          0.0 -> ...
      ```
      
      Where the second alternative matches where `ds` is +0.0 and *also* -0.0.
      However, the simplifier doesn't realize this and will introduce a local
      inlining of `ds = -- +0.0` as it believes this is the only
      value that matches this pattern.
      
      Instead of teaching the simplifier about floating-point semantics
      we simply prohibit case analysis on floating-point scrutinees and keep
      this logic in the comparison primops, where it belongs.
      
      We do several things here,
      
       - Add test cases from relevant tickets
       - Clean up a bit of documentation
       - Desugar literal matches against floats into applications of the
         appropriate equality primitive instead of case analysis
       - Add a CoreLint to ensure we don't pattern match on floats in Core
      
      Test Plan: validate with included testcases
      
      Reviewers: goldfire, simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1061
      
      GHC Trac Issues: #10215, #9238
      eb975d2e
  23. 24 Sep, 2015 1 commit
  24. 27 Jul, 2015 1 commit
    • A. Sandberg Eriksson's avatar
      Implementation of StrictData language extension · f842ad6c
      A. Sandberg Eriksson authored and Ben Gamari's avatar Ben Gamari committed
      This implements the `StrictData` language extension, which lets the
      programmer default to strict data fields in datatype declarations on a
      per-module basis.
      
      Specification and motivation can be found at
      https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
      
      This includes a tricky parser change due to conflicts regarding `~` in
      the type level syntax: all ~'s are parsed as strictness annotations (see
      `strict_mark` in Parser.y) and then turned into equality constraints at
      the appropriate places using `RdrHsSyn.splitTilde`.
      
      Updates haddock submodule.
      
      Test Plan: Validate through Harbormaster.
      
      Reviewers: goldfire, austin, hvr, simonpj, tibbe, bgamari
      
      Reviewed By: simonpj, tibbe, bgamari
      
      Subscribers: lelf, simonpj, alanz, goldfire, thomie, bgamari, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1033
      
      GHC Trac Issues: #8347
      f842ad6c
  25. 21 Jul, 2015 1 commit
    • Simon Peyton Jones's avatar
      Implement -dsuppress-unfoldings · a0e8bb74
      Simon Peyton Jones authored
      This extra "suppress" flag helps when there are a lot of Ids
      with big unfoldings that clutter up the dump
      
      Also slightly refactor printing of coercions in Core
      a0e8bb74
  26. 16 Jul, 2015 1 commit
  27. 14 Jul, 2015 1 commit
  28. 13 Jul, 2015 1 commit
  29. 05 Jul, 2015 1 commit
  30. 09 Jun, 2015 1 commit
  31. 26 May, 2015 1 commit
  32. 21 Apr, 2015 1 commit
  33. 07 Apr, 2015 1 commit
  34. 16 Jan, 2015 1 commit
    • Alexander Vershilov's avatar
      Trac #9878: Make the static form illegal in interpreted mode. · fffbf062
      Alexander Vershilov authored
      
      
      Summary:
      The entries of the static pointers table are expected to exist as
      object code. Thus we have ghci complain with an intelligible error
      message if the static form is used in interpreted mode.
      
      It also includes a fix to keysHashTable in Hash.c which could cause a
      crash. The iteration of the hashtable internals was incorrect. This
      patch has the function keysHashTable imitate the iteration in
      freeHashTable.
      
      Finally, we submit here some minor edits to comments and
      GHC.StaticPtr.StaticPtrInfo field names.
      
      Authored-by: Alexander Vershilov <alexander.vershilov@tweag.
      Authored-by: default avatarFacundo Domínguez <facundo.dominguez@tweag.io>
      
      Test Plan: ./validate
      
      Reviewers: simonpj, hvr, austin
      
      Reviewed By: austin
      
      Subscribers: carter, thomie, qnikst, mboes
      
      Differential Revision: https://phabricator.haskell.org/D586
      
      GHC Trac Issues: #9878
      fffbf062
  35. 22 Dec, 2014 1 commit
  36. 10 Dec, 2014 1 commit