1. 24 Sep, 2016 1 commit
    • Joachim Breitner's avatar
      Replace INLINEABLE by INLINABLE (#12613) · 68f72f10
      Joachim Breitner authored
      as the latter is the official, correct spelling, and the former just a
      misspelling accepted by GHC.
      
      Also document in the user’s guide that the alternative spelling is
      accepted
      
      This commit was brough to you by HIW 2016.
      68f72f10
  2. 21 Aug, 2016 1 commit
  3. 21 Jul, 2016 1 commit
  4. 22 Jun, 2016 1 commit
  5. 21 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Don't quantify over Refl in a RULE · d09e982c
      Simon Peyton Jones authored
      This fixes Trac #12212.  It's quite hard to provoke, but I've
      added a standalone test case that does so.
      
      The issue is explained in Note [Evidence foralls] in Specialise.
      d09e982c
  6. 15 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  7. 14 Jun, 2016 1 commit
    • niteria's avatar
      Rename cmpType to nonDetCmpType · 9d22fbe2
      niteria authored
      This makes it obvious that it's nondeterministic and hopefully
      will prevent someone from using it accidentally.
      
      GHC Trac: #4012
      9d22fbe2
  8. 06 Jun, 2016 1 commit
    • niteria's avatar
      Implement deterministic CallInfoSet · 48e9a1f5
      niteria authored
      We need CallInfoSet to be deterministic because it determines the
      order that the binds get generated.
      
      Currently it's not deterministic because it's keyed on
      `CallKey = [Maybe Type]` and `Ord CallKey` is implemented
      with `cmpType` which is nondeterministic.
      
      See Note [CallInfoSet determinism] for more details.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, austin, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2242
      
      GHC Trac Issues: #4012
      48e9a1f5
  9. 12 May, 2016 1 commit
    • niteria's avatar
      Kill varEnvElts in specImports · 6bf0eef7
      niteria authored
      We need the order of specialized binds and rules to be deterministic,
      so we use a deterministic set here.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, bgamari, austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2197
      
      GHC Trac Issues: #4012
      6bf0eef7
  10. 24 Mar, 2016 1 commit
    • Simon Peyton Jones's avatar
      Tidy up handling of coercion variables · cb08f8da
      Simon Peyton Jones authored
      * Comments to explain that a CoVar, whose IdInfo is CoVarId,
        is always unlifted (but may be nominal or representational role)
      
        And TyCoRep.isCoercionType picks out only those unlifted
        types, NOT the lifted versions
      
      * Introduce Var.NcId for non-co-var Ids
        with predicate isNonCoVarId
      
      * Add assertions in CoreSubst that the Id env is only
        used for NcIds
      
      * Fix lurking bug in CSE which extended the
        CoreSubst Id env with a CoVar
      
      * Fix two bugs in Specialise.spec_call, which wrongly treated
        CoVars like NcIds
          - needed a varToCoreExpr in one place
          - needed extendSubst not extendIdSubst in another
        This was the root cause of Trac #11644
      
      Minor refactoring
      
      * Eliminate unused mkDerivedLocalCoVarM, mkUserLocalCoVar
      * Small refactor in mkSysLocalOrCoVar
      cb08f8da
  11. 26 Feb, 2016 1 commit
  12. 19 Feb, 2016 1 commit
  13. 18 Feb, 2016 1 commit
    • 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)
      b5292557
  14. 11 Feb, 2016 1 commit
  15. 27 Jan, 2016 1 commit
  16. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  17. 31 Dec, 2015 2 commits
  18. 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
  19. 17 Nov, 2015 1 commit
    • quchen's avatar
      MonadFail proposal, phase 1 · 233d1312
      quchen authored
      This implements phase 1 of the MonadFail proposal (MFP, #10751).
      
      - MonadFail warnings are all issued as desired, tunable with two new flags
      - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings`
        (but it's disabled by default right now)
      
      Credits/thanks to
      - Franz Thoma, whose help was crucial to implementing this
      - My employer TNG Technology Consulting GmbH for partially funding us
        for this work
      
      Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma
      
      Reviewed By: hvr, bgamari, fmthoma
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1248
      
      GHC Trac Issues: #10751
      233d1312
  20. 17 Oct, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make Monad/Applicative instances MRP-friendly · e8ed2136
      Herbert Valerio Riedel authored
      This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e.
      such that the explicit definitions for `return` and `(>>)` match the
      MRP-style default-implementation, i.e.
      
        return = pure
      
      and
      
        (>>) = (*>)
      
      This way, e.g. all `return = pure` definitions can easily be grepped and
      removed in GHC 8.1;
      
      Test Plan: Harbormaster
      
      Reviewers: goldfire, alanz, bgamari, quchen, austin
      
      Reviewed By: quchen, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1312
      e8ed2136
  21. 10 Oct, 2015 1 commit
  22. 08 Oct, 2015 1 commit
  23. 02 Sep, 2015 1 commit
  24. 05 Aug, 2015 1 commit
    • Simon Peyton Jones's avatar
      Warn about missed specialisations for imports · a4261549
      Simon Peyton Jones authored
      This change was provoked by Trac #10720, where a missing
      INLINEABLE pragma gave very poor performance.
      
      The change is to warn when an imported function is not specialised
      in a situation where the user expects it to be.
      
      New flags
        -fwarn-missed-specialisations
        -fwarn-all-missed-specialisations
      
      Documented in user manual.
      See Note [Warning about missed specialisations]
      a4261549
  25. 03 Aug, 2015 1 commit
  26. 21 Jul, 2015 1 commit
  27. 06 Jul, 2015 1 commit
    • Ben Gamari's avatar
      Specialise: Avoid unnecessary recomputation of free variable information · 4681f559
      Ben Gamari authored
      When examining compile times for code with large ADTs (particularly those with
      many record constructors), I found that the specialiser contributed
      disproportionately to the compiler runtime. Some profiling suggested that
      the a great deal of time was being spent in `pair_fvs` being called from
      `consDictBind`.
      
      @simonpj pointed out that `flattenDictBinds` as called by `specBind` was
      unnecessarily discarding cached free variable information, which then needed to
      be recomputed by `pair_fvs`.
      
      Here I refactor the specializer to retain the free variable cache whenever
      possible.
      
      **Open Qustions**
      
       * I used `fst` in a couple of places to extract the bindings from a `DictBind`.
         Perhaps this is a sign that `DictBind` has outgrown its type synonym status?
      
      Test Plan: validate
      
      Reviewers: austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, bgamari, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1012
      
      GHC Trac Issues: #7450
      4681f559
  28. 28 Jun, 2015 1 commit
    • Ben Gamari's avatar
      Add -fcross-module-specialise flag · 89834d6d
      Ben Gamari authored
      Summary:
      As of 7.10.1 we specialize INLINEABLE identifiers defined in other
      modules. This can expose issues (compiler bugs or otherwise) in some cases
      (e.g. Trac #10491) and therefore we now provide a way for the user to disable
      this optimization.
      
      Test Plan: Successfully compile Splice.hs from Trac #10491.
      
      Reviewers: simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D999
      
      GHC Trac Issues: #10491
      89834d6d
  29. 20 Jun, 2015 1 commit
    • Edward Z. Yang's avatar
      Filter orphan rules based on imports, fixes #10294 and #10420. · 0cb1f5cf
      Edward Z. Yang authored
      Summary:
      If we have an orphan rule in our database, don't apply it
      unless the defining module is transitively imported by the
      module we are processing.  We do this by defining a new RuleEnv
      data type which includes both the RuleBase as well as the set
      of visible orphan modules, and threading this through the
      relevant environments (CoreReader, RuleCheckEnv and ScEnv).
      
      This is analogous to the instances fix we applied in #2182
      4c834fdd
      
      , but done for RULES.
      An important knock-on effect is that we can remove some buggy
      code in LoadInterface which tried to avoid loading interfaces
      that were loaded by plugins (which sometimes caused instances
      and rules to NEVER become visible).
      
      One note about tests: I renamed the old plugins07 test to T10420
      and replaced plugins07 with a test to ensure that a plugin
      import did not cause new rules to be loaded in.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D950
      
      GHC Trac Issues: #10420
      0cb1f5cf
  30. 18 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · ffc21506
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      
      - Haddock needs to absorb the change too; so there is a submodule update
      ffc21506
  31. 14 May, 2015 1 commit
    • Austin Seipp's avatar
      Revert multiple commits · 3cf8ecdc
      Austin Seipp authored
      This reverts multiple commits from Simon:
      
        - 04a484ea Test Trac #10359
        - a9ccd37a Test Trac #10403
        - c0aae6f6 Test Trac #10248
        - eb6ca851 Make the "matchable-given" check happen first
        - ca173aa3 Add a case to checkValidTyCon
        - 51cbad15 Update haddock submodule
        - 6e1174da Separate transCloVarSet from fixVarSet
        - a8493e03 Fix imports in HscMain (stage2)
        - a154944b Two wibbles to fix the build
        - 5910a1bc Change in capitalisation of error msg
        - 130e93aa Refactor tuple constraints
        - 8da785d5 Delete commented-out line
      
      These break the build by causing Haddock to fail mysteriously when
      trying to examine GHC.Prim it seems.
      3cf8ecdc
  32. 13 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      130e93aa
  33. 03 Dec, 2014 1 commit
  34. 17 Oct, 2014 1 commit
    • Joachim Breitner's avatar
      Avoid printing uniques in specialization rules · a477e811
      Joachim Breitner authored
      Akio found an avoidable cause of non-determinisim: The names of RULES
      generated by Specialise had uniques in them:
          "SPEC $cshowsPrec_a2QX @ [GHC.Types.Char]" [ALWAYS] forall ...
      By using showSDocForUser instead of showSDocDump when building the rule
      name, this is avoided:
          "SPEC $cshowsPrec @ [Char]" [ALWAYS] forall ...
      See #4012, comments 61ff.
      a477e811
  35. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      
      
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  36. 29 Aug, 2014 2 commits
  37. 28 Aug, 2014 2 commits
    • Simon Peyton Jones's avatar
      Comments only · 86a2ebf8
      Simon Peyton Jones authored
      86a2ebf8
    • Simon Peyton Jones's avatar
      Add -fspecialise-aggressively · b9e49d3e
      Simon Peyton Jones authored
      This flag specialises any imported overloaded function that has an
      unfolding, whether or not it was marked INLINEABLE.
      
      We get a lot of orphan SPEC rules as a result, but that doesn't matter
      provided we don't treat orphan auto-generated rules as causing the module
      itself to be an orphan module.  See Note [Orphans and auto-generated rules]
      in MkIface.
      b9e49d3e