1. 11 Nov, 2015 1 commit
    • Alan Zimmerman's avatar
      Remove fun_infix from Funbind, as it is now in Match · f0f9365f
      Alan Zimmerman authored
      One of the changes D538 introduced is to add `m_fun_id_infix` to `Match`
      
      ```lang=hs
      data Match id body
        = Match {
              m_fun_id_infix :: (Maybe (Located id,Bool)),
                -- fun_id and fun_infix for functions with multiple equations
                -- only present for a RdrName. See note [fun_id in Match]
              m_pats :: [LPat id], -- The patterns
              m_type :: (Maybe (LHsType id)),
                                       -- A type signature for the result of the match
                                       -- Nothing after typechecking
              m_grhss :: (GRHSs id body)
        } deriving (Typeable)
      ```
      
      This was done to track the individual locations and fixity of the
      `fun_id` for each of the defining equations for a function when there
      are more than one.
      
      For example, the function `(&&&)` is defined with some prefix and some
      infix equations below.
      
      ```lang=hs
          (&&&  ) [] [] =  []
          xs    &&&   [] =  xs
          (  &&&  ) [] ys =  ys
      ```
      
      This means that the fun_infix is now superfluous in the `FunBind`. This
      has not been removed as a potentially risky change just before 7.10 RC2,
      and so must be done after.
      
      This ticket captures that task, which includes processing these fields
      through the renamer and beyond.
      
      Ticket #9988 introduced these fields into `Match` through renaming, this
      ticket it to continue through type checking and then remove it from
      `FunBind` completely.
      
      The split happened so that #9988 could land in 7.10
      
      Trac ticket : #10061
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1285
      
      GHC Trac Issues: #10061
      f0f9365f
  2. 07 Nov, 2015 1 commit
    • Matthew Pickering's avatar
      Remove PatSynBuilderId · 22080113
      Matthew Pickering authored
      Summary:
      It was only used to pass field labels between the typechecker and
      desugarer. Instead we add an extra field the RecordCon to carry this
      information.
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1443
      
      GHC Trac Issues: #11057
      22080113
  3. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      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
  4. 29 Oct, 2015 4 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
    • Ben Gamari's avatar
    • Matthew Pickering's avatar
      Record pattern synonyms · 2a74a64e
      Matthew Pickering authored
      This patch implements an extension to pattern synonyms which allows user
      to specify pattern synonyms using record syntax. Doing so generates
      appropriate selectors and update functions.
      
      === Interaction with Duplicate Record Fields ===
      
      The implementation given here isn't quite as general as it could be with
      respect to the recently-introduced `DuplicateRecordFields` extension.
      
      Consider the following module:
      
          {-# LANGUAGE DuplicateRecordFields #-}
          {-# LANGUAGE PatternSynonyms #-}
      
          module Main where
      
          pattern S{a, b} = (a, b)
          pattern T{a}    = Just a
      
          main = do
            print S{ a = "fst", b = "snd" }
            print T{ a = "a" }
      
      In principle, this ought to work, because there is no ambiguity. But at
      the moment it leads to a "multiple declarations of a" error. The problem
      is that pattern synonym record selectors don't do the same name mangling
      as normal datatypes when DuplicateRecordFields is enabled. They could,
      but this would require some work to track the field label and selector
      name separately.
      
      In particular, we currently represent datatype selectors in the third
      component of AvailTC, but pattern synonym selectors are just represented
      as Avails (because they don't have a corresponding type constructor).
      Moreover, the GlobalRdrElt for a selector currently requires it to have
      a parent tycon.
      
      (example due to Adam Gundry)
      
      === Updating Explicitly Bidirectional Pattern Synonyms ===
      
      Consider the following
      
      ```
      pattern Silly{a} <- [a] where
        Silly a = [a, a]
      
      f1 = a [5] -- 5
      
      f2 = [5] {a = 6} -- currently [6,6]
      ```
      
      === Fixing Polymorphic Updates ===
      
      They were fixed by adding these two lines in `dsExpr`. This might break
      record updates but will be easy to fix.
      
      ```
      + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs)
      
      - , pat_wrap = idHsWrapper }
      +, pat_wrap = req_wrap }
      ```
      
      === Mixed selectors error ===
      
      Note [Mixed Record Field Updates]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Consider the following pattern synonym.
      
          data MyRec = MyRec { foo :: Int, qux :: String }
      
          pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2}
      
      This allows updates such as the following
      
          updater :: MyRec -> MyRec
          updater a = a {f1 = 1 }
      
      It would also make sense to allow the following update (which we
      reject).
      
          updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two"
      
      This leads to confusing behaviour when the selectors in fact refer the
      same field.
      
          updater a = a {f1 = 1, foo = 2} ==? ???
      
      For this reason, we reject a mixture of pattern synonym and normal
      record selectors in the same update block. Although of course we still
      allow the following.
      
          updater a = (a {f1 = 1}) {foo = 2}
      
          > updater (MyRec 0 "str")
          MyRec 2 "str"
      2a74a64e
  5. 27 Oct, 2015 1 commit
  6. 12 Oct, 2015 1 commit
    • Simon Peyton Jones's avatar
      Reinstate monomorphism-restriction warnings · f8fbf385
      Simon Peyton Jones authored
      This patch is driven by Trac #10935, and reinstates the
      -fwarn-monomorphism-restriction warning.  It was first lost in 2010:
      d2ce0f52 "Super-monster patch implementing the new typechecker -- at
      last"
      
      I think the existing documentation is accurate; it is not even
      turned on by -Wall.
      
      I added one test.
      f8fbf385
  7. 05 Aug, 2015 1 commit
    • Simon Peyton Jones's avatar
      Tidy up and refactor wildcard handling · 95364812
      Simon Peyton Jones authored
      When examining #10615, I found the wildcard handling hard
      to understand.  This patch refactors quite a bit, but with
      no real change in behaviour.
      
       * Split out TcIdSigInfo from TcSigInfo, as a separate type,
         like TcPatSynInfo.
      
       * Make TcIdSigInfo express more invariants by pushing the
         wildard info into TcIdSigBndr
      
       * Remove all special treatment of unification variables that arise
         from wildcards; so the TauTv of TcType.MetaInfo loses its Bool
         argument.
      
      A ton of konck on changes.  The result is significantly simpler, I think.
      95364812
  8. 21 Jul, 2015 1 commit
    • Simon Peyton Jones's avatar
      Add NOINLINE for hs-boot functions · efa7b3a4
      Simon Peyton Jones authored
      This fixes Trac #10083.
      
      The key change is in TcBinds.tcValBinds, where we construct
      the prag_fn.  With this patch we add a NOINLINE pragma for
      any functions that were exported by the hs-boot file for this
      module.
      
      See Note [Inlining and hs-boot files], and #10083, for details.
      
      The commit touches several other files becuase I also changed the
      representation of the "pragma function" from a function TcPragFun
      to an environment, TcPragEnv. This makes it easer to extend
      during construction.
      efa7b3a4
  9. 06 May, 2015 2 commits
  10. 24 Mar, 2015 1 commit
    • Simon Peyton Jones's avatar
      Improve environment handling in TcBinds · 8eaa70a6
      Simon Peyton Jones authored
      This is a minor refactoring, but it simplifies the code quite a bit
      
      * Decrease the number of variants of tcExtend in TcEnv
      * Remove "not_actually_free" from TcEnv.tc_extend_local_env2
      * Simplify plumbingof the "closed" flag
      * Remove redundant scoping of wild-card variables
      8eaa70a6
  11. 10 Feb, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor the handling of quasi-quotes · f46360ed
      Simon Peyton Jones authored
      As Trac #10047 points out, a quasi-quotation [n|...blah...|] is supposed
      to behave exactly like $(n "...blah...").  But it doesn't!  This was outright
      wrong: quasiquotes were being run even inside brackets.
      
      Now that TH supports both typed and untyped splices, a quasi-quote is properly
      regarded as a particular syntax for an untyped splice. But apart from that
      they should be treated the same.  So this patch refactors the handling of
      quasiquotes to do just that.
      
      The changes touch quite a lot of files, but mostly in a routine way.
      The biggest changes by far are in RnSplice, and more minor changes in
      TcSplice.  These are the places where there was real work to be done.
      Everything else is routine knock-on changes.
      
      * No more QuasiQuote forms in declarations, expressions, types, etc.
        So we get rid of these data constructors
          * HsBinds.QuasiQuoteD
          * HsExpr.HsSpliceE
          * HsPat.QuasiQuotePat
          * HsType.HsQuasiQuoteTy
      
      * We get rid of the HsQuasiQuote type altogether
      
      * Instead, we augment the HsExpr.HsSplice type to have three
        consructors, for the three types of splice:
          * HsTypedSplice
          * HsUntypedSplice
          * HsQuasiQuote
        There are some related changes in the data types in HsExpr near HsSplice.
        Specifically: PendingRnSplice, PendingTcSplice, UntypedSpliceFlavour.
      
      * In Hooks, we combine rnQuasiQuoteHook and rnRnSpliceHook into one.
        A smaller, clearer interface.
      
      * We have to update the Haddock submodule, to accommodate the hsSyn changes
      f46360ed
  12. 20 Jan, 2015 1 commit
  13. 19 Jan, 2015 2 commits
  14. 16 Jan, 2015 1 commit
    • Alan Zimmerman's avatar
      API Annotations tweaks. · 11881ec6
      Alan Zimmerman authored
      Summary:
      HsTyLit now has SourceText
      
      Update documentation of HsSyn to reflect which annotations are attached to which element.
      
      Ensure that the parser always keeps HsSCC and HsTickPragma values, to
      be ignored in the desugar phase if not needed
      
      Bringing in SourceText for pragmas
      
      Add Location in NPlusKPat
      
      Add Location in FunDep
      
      Make RecCon payload Located
      
      Explicitly add AnnVal to RdrName where it is compound
      
      Add Location in IPBind
      
      Add Location to name in IEThingAbs
      
      Add Maybe (Located id,Bool) to Match to track fun_id,infix
        This includes converting Match into a record and adding a note about why
        the fun_id needs to be replicated in the Match.
      
      Add Location in KindedTyVar
      
      Sort out semi-colons for parsing
      
        - import statements
        - stmts
        - decls
        - decls_cls
        - decls_inst
      
      This updates the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D538
      11881ec6
  15. 06 Jan, 2015 1 commit
    • Simon Peyton Jones's avatar
      Major patch to add -fwarn-redundant-constraints · 32973bf3
      Simon Peyton Jones authored
      The idea was promted by Trac #9939, but it was Christmas, so I did
      some recreational programming that went much further.
      
      The idea is to warn when a constraint in a user-supplied context is
      redundant.  Everything is described in detail in
        Note [Tracking redundant constraints]
      in TcSimplify.
      
      Main changes:
      
       * The new ic_status field in an implication, of type ImplicStatus.
         It replaces ic_insol, and includes information about redundant
         constraints.
      
       * New function TcSimplify.setImplicationStatus sets the ic_status.
      
       * TcSigInfo has sig_report_redundant field to say whenther a
         redundant constraint should be reported; and similarly
         the FunSigCtxt constructor of UserTypeCtxt
      
       * EvBinds has a field eb_is_given, to record whether it is a given
         or wanted binding. Some consequential chagnes to creating an evidence
         binding (so that we record whether it is given or wanted).
      
       * AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds;
         see Note [Typechecking plan for instance declarations] in
         TcInstDcls
      
       * Some significant changes to the type checking of instance
         declarations; Note [Typechecking plan for instance declarations]
         in TcInstDcls.
      
       * I found that TcErrors.relevantBindings was failing to zonk the
         origin of the constraint it was looking at, and hence failing to
         find some relevant bindings.  Easy to fix, and orthogonal to
         everything else, but hard to disentangle.
      
      Some minor refactorig:
      
       * TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds
      
       * TcClassDcl and TcInstDcls now have their own code for typechecking
         a method body, rather than sharing a single function. The shared
         function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code
         and the differences were growing confusing.
      
       * Add new function TcRnMonad.pushLevelAndCaptureConstraints, and
         use it
      
       * Add new function Bag.catBagMaybes, and use it in TcSimplify
      32973bf3
  16. 20 Dec, 2014 1 commit
  17. 16 Dec, 2014 1 commit
  18. 15 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Pattern-synonym matcher and builder Ids must be *LocalIds* · fbb42b2e
      Simon Peyton Jones authored
      This easy-to-make mistake meant that pattern-synonym matcher and
      builder Ids weren't being treated as locally defined by the simpplier.
      That meant that we never looked up them up in the environment, got an
      out-of-date unfolding, which made the Simplifier fall into an infinite
      loop.  This was the cause of Trac #98587, but it was quite tricky to
      find!
      
      In a separate patch I'll make Lint check for locally-bound GlobalIds,
      since they are always an error.
      fbb42b2e
  19. 03 Dec, 2014 1 commit
  20. 02 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Rename Untouchables to TcLevel · 26a3d0fe
      Simon Peyton Jones authored
      This is a long-overdue renaming
         Untouchables  -->   TcLevel
      It is renaming only; no change in functionality.
      
      We really wanted to get this done before the 7.10 fork.
      26a3d0fe
  21. 28 Nov, 2014 1 commit
  22. 21 Nov, 2014 2 commits
    • Alan Zimmerman's avatar
      AST changes to prepare for API annotations, for #9628 · 7927658e
      Alan Zimmerman authored
      Summary:
      AST changes to prepare for API annotations
      
      Add locations to parts of the AST so that API annotations can
      then be added.
      
      The outline of the whole process is captured here
      https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations
      
      This change updates the haddock submodule.
      
      Test Plan: sh ./validate
      
      Reviewers: austin, simonpj, Mikolaj
      
      Reviewed By: simonpj, Mikolaj
      
      Subscribers: thomie, goldfire, carter
      
      Differential Revision: https://phabricator.haskell.org/D426
      
      GHC Trac Issues: #9628
      7927658e
    • Simon Peyton Jones's avatar
      Rejig builders for pattern synonyms, especially unlifted ones · e8762081
      Simon Peyton Jones authored
      When a pattern synonym is for an unlifted pattern, its "builder" would
      naturally be a top-level unlifted binding, which isn't allowed.  So we
      give it an extra Void# argument.
      
      Our Plan A involved then making *two* Ids for these builders, with
      some consequential fuss in the desugarer.  This was more pain than I
      liked, so I've re-jigged it.
      
       * There is just one builder for a pattern synonym.
      
       * It may have an extra Void# arg, but this decision is signalled
         by the Bool in the psBuilder field.
      
         I did the same for the psMatcher field.
      
         Both Bools are serialised into interface files, so there is
         absolutely no doubt whether that extra Void# argument is required.
      
       * I renamed "wrapper" to "builder".  We have too may "wrappers"
      
       * In order to deal with typecchecking occurrences of P in expressions,
         I refactored the tcInferId code in TcExpr.
      
      All of this allowed me to revert 5fe872
         "Apply compulsory unfoldings during desugaring, except for `seq` which is special."
      which turned out to be a rather messy hack in DsBinds
      e8762081
  23. 20 Nov, 2014 1 commit
    • Gergő Érdi's avatar
      Add support for pattern synonym type signatures. · cce6318e
      Gergő Érdi authored
      Syntax is of the form
      
          pattern P :: (Prov b) => (Req a) => a -> b -> Int -> T a
      
      which declares a pattern synonym called `P`, with argument types `a`, `b`,
      and `Int`, and result type `T a`, with provided context `(Prov b)` and required
      context `(Req a)`.
      
      The Haddock submodule is also updated to use this new syntax in generated docs.
      cce6318e
  24. 13 Nov, 2014 2 commits
  25. 08 Nov, 2014 2 commits
    • Gergő Érdi's avatar
    • Gergő Érdi's avatar
      In pattern synonym matchers, support unboxed continuation results (fixes #9783). · 474e535b
      Gergő Érdi authored
      This requires ensuring the continuations have arguments by adding a dummy
      Void# argument when needed. This is so that matching on a pattern synonym
      is lazy even when the result is unboxed, e.g.
      
          pattern P = ()
          f P = 0#
      
      In this case, without dummy arguments, the generated matcher's type would be
      
         $mP :: forall (r :: ?). () -> r -> r -> r
      
      which is called in `f` at type `() -> Int# -> Int# -> Int#`,
      so it would be strict, in particular, in the failure continuation
      of `patError`.
      
      We work around this by making sure both continuations have arguments:
      
        $mP :: forall (r :: ?). () -> (Void# -> r) -> (Void# -> r) -> r
      
      Of course, if `P` (and thus, the success continuation) has any arguments,
      we are only adding the extra dummy argument to the failure continuation.
      474e535b
  26. 04 Nov, 2014 1 commit
    • Simon Peyton Jones's avatar
      Get the Untouchables level right in simplifyInfer · e11e1b80
      Simon Peyton Jones authored
      Previously we could get constraints in which the untouchables-level did not
      strictly increase, which is one of the main invariants!
      
      This patch also simplifies and modularises the tricky case of generalising
      an inferred let-binding
      e11e1b80
  27. 21 Sep, 2014 1 commit
  28. 06 Sep, 2014 1 commit
  29. 29 Jul, 2014 3 commits
  30. 06 Jun, 2014 1 commit
    • Simon Peyton Jones's avatar
      Make the matcher and wrapper Ids in PatSyn into LocalIds, not GlobalIds · 7ac600d5
      Simon Peyton Jones authored
      This was a serious bug, exposed by Trac #9175.  The matcher and wrapper
      must be LocalIds, like record selectors and dictionary functions, for
      the reasons now documented in Note [Exported LocalIds] in Id.lhs
      
      In fixing this I found
       - PatSyn should have an Id inside it (apart from the wrapper and matcher)
         It should be a Name.  Hence psId --> psName, with knock-on consequences
      
       - Tidying of PatSyns in TidyPgm was wrong
      
       - The keep-alive set in Desugar.deSugar (now) doesn't need pattern synonyms
         in it
      
      I also cleaned up the interface to PatSyn a little, so there's a tiny knock-on
      effect in Haddock; hence the haddock submodule update.
      
      It's very hard to make a test for this bug, so I haven't.
      7ac600d5