1. 10 Jul, 2018 1 commit
    • Ningning Xie's avatar
      Refactor coercion rule · 55a3f855
      Ningning Xie authored
      Summary:
      The patch is an attempt on #15192.
      
      It defines a new coercion rule
      
      ```
       | GRefl Role Type MCoercion
      ```
      
      which correspondes to the typing rule
      
      ```
           t1 : k1
        ------------------------------------
        GRefl r t1 MRefl: t1 ~r t1
      
           t1 : k1       co :: k1 ~ k2
        ------------------------------------
        GRefl r t1 (MCo co) : t1 ~r t1 |> co
      ```
      
      MCoercion wraps a coercion, which might be reflexive (MRefl)
      or not (MCo co). To know more about MCoercion see #14975.
      
      We keep Refl ty as a special case for nominal reflexive coercions,
      naemly, Refl ty :: ty ~n ty.
      
      This commit is meant to be a general performance improvement,
      but there are a few regressions. See #15192, comment:13 for
      more information.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, goldfire, simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15192
      
      Differential Revision: https://phabricator.haskell.org/D4747
      55a3f855
  2. 15 Jun, 2018 1 commit
    • Sylvain Henry's avatar
      Built-in Natural literals in Core · fe770c21
      Sylvain Henry authored
      Add support for built-in Natural literals in Core.
      
      - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber
        constructor with a LitNumType field
      - Support built-in Natural literals
      - Add desugar warning for negative literals
      - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency
        reasons
      
      This patch introduces only a few rules for Natural literals (compared
      to Integer's rules). Factorization of the built-in rules for numeric
      literals will be done in another patch as this one is already big to
      review.
      
      Test Plan:
        validate
        test build with integer-simple
      
      Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton,
      thomie
      
      GHC Trac Issues: #14170, #14465
      
      Differential Revision: https://phabricator.haskell.org/D4212
      fe770c21
  3. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  4. 20 Apr, 2018 1 commit
    • Tobias Dammers's avatar
      Caching coercion roles in NthCo and coercionKindsRole refactoring · 2fbe0b51
      Tobias Dammers authored
      While addressing nonlinear behavior related to coercion roles,
      particularly `NthCo`, we noticed that coercion roles are recalculated
      often even though they should be readily at hand already in most cases.
      This patch adds a `Role` to the `NthCo` constructor so that we can cache
      them rather than having to recalculate them on the fly.
      https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the
      approach.
      
      Performance improvement over GHC HEAD, when compiling Grammar.hs (see below):
      
      GHC 8.2.1:
      ```
      ghc Grammar.hs  176.27s user 0.23s system 99% cpu 2:56.81 total
      ```
      
      before patch (but with other optimizations applied):
      ```
      ghc Grammar.hs -fforce-recomp  175.77s user 0.19s system 100% cpu 2:55.78 total
      ```
      
      after:
      ```
      ../../ghc/inplace/bin/ghc-stage2 Grammar.hs  10.32s user 0.17s system 98% cpu 10.678 total
      ```
      
      Introduces the following regressions:
      
      - perf/compiler/parsing001 (possibly false positive)
      - perf/compiler/T9872
      - perf/compiler/haddock.base
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #11735
      
      Differential Revision: https://phabricator.haskell.org/D4394
      2fbe0b51
  5. 19 Mar, 2018 2 commits
    • Ryan Scott's avatar
      Fix #14934 by including axSub0R in typeNatCoAxiomRules · c3aea396
      Ryan Scott authored
      For some reason, `axSub0R` was left out of `typeNatCoAxiomRules` in
      `TcTypeNats`, which led to disaster when trying to look up `Sub0R` from
      an interface file, as demonstrated in #14934.
      
      The fix is simple—just add `axSub0R` to that list. To help prevent
      an issue like this happening in the future, I added a
      `Note [Adding built-in type families]` to `TcTypeNats`, which
      contains a walkthrough of all the definitions in `TcTypeNats` you
      need to update when adding a new built-in type family.
      
      Test Plan: make test TEST=T14934
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14934
      
      Differential Revision: https://phabricator.haskell.org/D4508
      c3aea396
    • Simon Peyton Jones's avatar
      Comments and tiny refactor · 2a3702d8
      Simon Peyton Jones authored
      Related to Ryan's upcoming patch for Trac #14933
      2a3702d8
  6. 10 Jan, 2018 1 commit
    • niteria's avatar
      Lift constructor tag allocation out of a loop · dbdf77d9
      niteria authored
      Before this change, for each constructor that we want
      to allocate a tag for we would traverse a list of all
      the constructors in a datatype to determine which tag
      a constructor should get.
      
      This is obviously quadratic and for datatypes with 10k
      constructors it actually makes a big difference.
      
      This change implements the plan outlined by @simonpj in
      https://mail.haskell.org/pipermail/ghc-devs/2017-October/014974.html
      which is basically about using a map and constructing it outside the
      loop.
      
      One place where things got a bit awkward was TysWiredIn.hs,
      it would have been possible to just assign the tags by hand, but
      that seemed error-prone to me, so I decided to go through a map
      there as well.
      
      Test Plan:
      ./validate
      On a file with 10k constructors
      Before:
         8,130,522,344 bytes allocated in the heap
        Total   time    3.682s  (  3.920s elapsed)
      After:
         4,133,478,744 bytes allocated in the heap
        Total   time    2.509s  (  2.750s elapsed)
      
      Reviewers: simonpj, bgam...
      dbdf77d9
  7. 21 Dec, 2017 1 commit
    • Simon Peyton Jones's avatar
      Refactor coercion holes · a492af06
      Simon Peyton Jones authored
      In fixing Trac #14584 I found that it would be /much/ more
      convenient if a "hole" in a coercion (much like a unification
      variable in a type) acutally had a CoVar associated with it
      rather than just a Unique.  Then I can ask what the free variables
      of a coercion is, and get a set of CoVars including those
      as-yet-un-filled in holes.
      
      Once that is done, it makes no sense to stuff coercion holes
      inside UnivCo.  They were there before so we could know the
      kind and role of a "hole" coercion, but once there is a CoVar
      we can get that info from the CoVar.  So I removed HoleProv
      from UnivCoProvenance and added HoleCo to Coercion.
      
      In summary:
      
      * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance
      
      * Similarly in IfaceCoercion
      
      * Make CoercionHole have a CoVar in it, not a Unique
      
      * Make tyCoVarsOfCo return the free coercion-hole variables
        as well as the ordinary free CoVars.  Similarly, remember
        to zonk the CoVar in a CoercionHole
      
      We could go further, and remove CoercionHole as a distinct type
      altogther, just collapsing it into HoleCo.  But I have not done
      that yet.
      a492af06
  8. 01 Dec, 2017 1 commit
    • Edward Z. Yang's avatar
      Make use of boot TyThings during typechecking. · 69987720
      Edward Z. Yang authored
      
      
      Summary:
      Suppose that you are typechecking A.hs, which transitively imports,
      via B.hs, A.hs-boot.  When we poke on B.hs and discover that it
      has a reference to a type from A, what TyThing should we wire
      it up with?  Clearly, if we have already typechecked A, we
      should use the most up-to-date TyThing: the one we freshly
      generated when we typechecked A.  But what if we haven't typechecked
      it yet?
      
      For the longest time, GHC adopted the policy that this was
      *an error condition*; that you MUST NEVER poke on B.hs's reference
      to a thing defined in A.hs until A.hs has gotten around to checking
      this.  However, actually ensuring this is the case has proven
      to be a bug farm.  The problem was especially poignant with
      type family consistency checks, which eagerly happen before
      any typechecking takes place.
      
      This patch takes a different strategy: if we ever try to access
      an entity from A which doesn't exist, we just fall back on the
      definition of A from the hs-boot file.  This means that you may
      end up with a mix of A.hs and A.hs-boot TyThings during the
      course of typechecking.
      Signed-off-by: Edward Z. Yang's avatarEdward Z. Yang <ezyang@fb.com>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin, goldfire
      
      Subscribers: thomie, rwbarton
      
      GHC Trac Issues: #14396
      
      Differential Revision: https://phabricator.haskell.org/D4154
      69987720
  9. 09 Nov, 2017 1 commit
  10. 03 Oct, 2017 1 commit
    • Ryan Scott's avatar
      Track the order of user-written tyvars in DataCon · ef26182e
      Ryan Scott authored
      After typechecking a data constructor's type signature, its type
      variables are partitioned into two distinct groups: the universally
      quantified type variables and the existentially quantified type
      variables. Then, when prompted for the type of the data constructor,
      GHC gives this:
      
      ```lang=haskell
      MkT :: forall <univs> <exis>. (...)
      ```
      
      For H98-style datatypes, this is a fine thing to do. But for GADTs,
      this can sometimes produce undesired results with respect to
      `TypeApplications`. For instance, consider this datatype:
      
      ```lang=haskell
      data T a where
        MkT :: forall b a. b -> T a
      ```
      
      Here, the user clearly intended to have `b` be available for visible
      type application before `a`. That is, the user would expect
      `MkT @Int @Char` to be of type `Int -> T Char`, //not//
      `Char -> T Int`. But alas, up until now that was not how GHC
      operated—regardless of the order in which the user actually wrote
      the tyvars, GHC would give `MkT` the type:
      
      ```lang=haskell
      MkT :: forall a b. b -> T a
      ```
      
      Since `a` is universal and `b` is existential. This makes predicting
      what order to use for `TypeApplications` quite annoying, as
      demonstrated in #11721 and #13848.
      
      This patch cures the problem by tracking more carefully the order in
      which a user writes type variables in data constructor type
      signatures, either explicitly (with a `forall`) or implicitly
      (without a `forall`, in which case the order is inferred). This is
      accomplished by adding a new field `dcUserTyVars` to `DataCon`, which
      is a subset of `dcUnivTyVars` and `dcExTyVars` that is permuted to
      the order in which the user wrote them. For more details, refer to
      `Note [DataCon user type variables]` in `DataCon.hs`.
      
      An interesting consequence of this design is that more data
      constructors require wrappers. This is because the workers always
      expect the first arguments to be the universal tyvars followed by the
      existential tyvars, so when the user writes the tyvars in a different
      order, a wrapper type is needed to swizzle the tyvars around to match
      the order that the worker expects. For more details, refer to
      `Note [Data con wrappers and GADT syntax]` in `MkId.hs`.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: ezyang, goldfire, rwbarton, thomie
      
      GHC Trac Issues: #11721, #13848
      
      Differential Revision: https://phabricator.haskell.org/D3687
      ef26182e
  11. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  12. 29 Aug, 2017 1 commit
    • Simon Peyton Jones's avatar
      Small refactor of getRuntimeRep · a6c448b4
      Simon Peyton Jones authored
      Instead of using a string argument, use HasDebugCallStack.
      (Oddly, some functions were using both!)
      
      Plus, use getRuntimeRep rather than getRuntimeRep_maybe when
      if the caller panics on Nothing. Less code, and a better debug
      stack.
      a6c448b4
  13. 28 Jul, 2017 1 commit
  14. 27 Jul, 2017 1 commit
  15. 26 Jul, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix binder visiblity for default methods · 75bf11c0
      Simon Peyton Jones authored
      Trac #13998 showed that default methods were getting bogus tyvar
      binder visiblity info; and that it matters in the code genreated
      by the default-method fill-in mechanism
      
      * The actual fix: in TcTyDecls.mkDefaultMethodType, make TyVarBinders
        with the right visibility info by getting TyConBinders from the
        class TyCon.  (Previously we made up visiblity info, but that
        caused #13998.)
      
      * Define TyCon.tyConTyVarBinders :: [TyConBinder] -> [TyVarBinder]
        which can build correct forall binders for
          a) default methods (Trac #13998)
          b) data constructors
        This was originally BuildTyCl.mkDataConUnivTyVarBinders
      
      * Move mkTyVarBinder, mkTyVarBinders from Type to Var
      75bf11c0
  16. 20 Jul, 2017 1 commit
  17. 09 Mar, 2017 1 commit
  18. 06 Mar, 2017 1 commit
    • Ben Gamari's avatar
      Read COMPLETE sets from external packages · 8ca4bb1c
      Ben Gamari authored
      Currently, `COMPLETE` pragmas are not read from external packages at
      all, which quite limits their usefulness. This extends
      `ExternalPackageState` to include `COMPLETE` sets from other packages,
      and plumbs around the appropriate values to make it work the way you'd
      expect it to.
      
      Requires a `binary` submodule update.
      
      Fixes #13350.
      
      Test Plan: make test TEST=T13350
      
      Reviewers: rwbarton, mpickering, austin, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3257
      8ca4bb1c
  19. 03 Mar, 2017 2 commits
  20. 02 Mar, 2017 2 commits
    • Edward Z. Yang's avatar
      Fix roles merging to apply only to non-rep-injective types. · df919fb2
      Edward Z. Yang authored
      Test Plan: validate
      
      Reviewers: simonpj
      
      Subscribers:
      df919fb2
    • Edward Z. Yang's avatar
      Properly represent abstract classes in Class and IfaceDecl · fb5cd9d6
      Edward Z. Yang authored
      
      
      Summary:
      Previously, abstract classes looked very much like normal
      classes, except that they happened to have no methods,
      superclasses or ATs, and they came from boot files.  This
      patch gives abstract classes a proper representation in
      Class and IfaceDecl, by moving the things which are never
      defined for abstract classes into ClassBody/IfaceClassBody.
      
      Because Class is abstract, this change had ~no disruption
      to any of the code in GHC; if you ask about the methods of
      an abstract class, we'll just give you an empty list.
      
      This also fixes a bug where abstract type classes were incorrectly
      treated as representationally injective (they're not!)
      
      Fixes #13347, and a TODO in the code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3236
      fb5cd9d6
  21. 01 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Improve pretty-printing of types · 871b63e4
      Simon Peyton Jones authored
      When doing debug-printing it's really important that the free vars
      of a type are printed with their uniques.  The IfaceTcTyVar thing
      was a stab in that direction, but it only worked for TcTyVars, not
      TyVars.
      
      This patch does it properly, by keeping track of the free vars of the
      type when translating Type -> IfaceType, and passing that down through
      toIfaceTypeX.  Then when we find a variable, look in that set, and
      translate it to IfaceFreeTyVar if so.  (I renamed IfaceTcTyVar to
      IfaceFreeTyVar.)
      
      Fiddly but not difficult.
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3201
      871b63e4
  22. 27 Feb, 2017 2 commits
    • Edward Z. Yang's avatar
      Subtyping for roles in signatures. · 923d7ca2
      Edward Z. Yang authored
      
      
      Summary:
      This commit implements the plan in #13140:
      
      * Today, roles in signature files default to representational. Let's change the
        default to nominal, as this is the most flexible implementation side. If a
        client of the signature needs to coerce with a type, the signature can be
        adjusted to have more stringent requirements.
      
      * If a parameter is declared as nominal in a signature, it can be implemented
        by a data type which is actually representational.
      
      * When merging abstract data declarations, we take the smallest role for every
        parameter. The roles are considered fix once we specify the structure of an
        ADT.
      
      * Critically, abstract types are NOT injective, so we aren't allowed to
        make inferences like "if T a ~R T b, then a ~N b" based on the nominal
        role of a parameter in an abstract type (this would be unsound if the
        parameter ended up being phantom.)  This restriction is similar to the
        restriction we have on newtypes.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3123
      923d7ca2
    • Edward Z. Yang's avatar
      Treat all TyCon with hole names as skolem abstract. · 9603de6a
      Edward Z. Yang authored
      
      
      Summary:
      Fixes #13335.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: goldfire, austin, simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3211
      9603de6a
  23. 24 Feb, 2017 1 commit
    • Edward Z. Yang's avatar
      Record full FieldLabel in ifConFields. · 9d17028f
      Edward Z. Yang authored
      
      
      Summary:
      The previous implementation tried to be "efficient" by
      storing field names once in IfaceConDecls, and only just
      enough information for us to reconstruct the FieldLabel.
      But this came at a bit of code complexity cost.
      
      This patch undos the optimization, instead storing a full
      FieldLabel at each data constructor.  Consequently, this fixes
      bugs #12699 and #13250.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: adamgundry, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3174
      9d17028f
  24. 17 Feb, 2017 1 commit
    • Edward Z. Yang's avatar
      Fix a Backpack recompilation avoidance bug when signatures change. · ca543154
      Edward Z. Yang authored
      
      
      Summary:
      Recompilation avoidance checks if -this-unit-id has changed by relying
      on the "wanted module" check in readIface ("Something is amiss...").
      Unfortunately, this check didn't check if the instantiation made
      sense, which meant that if you changed the signatures of a Backpack
      package, we'd still treat the old signatures as up-to-date.
      
      The way I fixed this was by having findAndReadIface take in a 'Module'
      representing the /actual/ module we were intending to lookup.  We
      convert this into the 'Module' we expect to see in 'mi_module' and
      now do a more elaborate check that will also verify that instantiations
      make sense.
      
      Along the way, I robustified the logging infrastructure for
      recompilation checking, and folded wrongIfaceModErr (which
      was dead code) into the error message.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, austin
      
      Subscribers: thomie, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3130
      ca543154
  25. 02 Feb, 2017 1 commit
  26. 01 Feb, 2017 1 commit
  27. 26 Jan, 2017 1 commit
    • Matthew Pickering's avatar
      COMPLETE pragmas for enhanced pattern exhaustiveness checking · 1a3f1eeb
      Matthew Pickering authored
      This patch adds a new pragma so that users can specify `COMPLETE` sets of
      `ConLike`s in order to sate the pattern match checker.
      
      A function which matches on all the patterns in a complete grouping
      will not cause the exhaustiveness checker to emit warnings.
      
      ```
      pattern P :: ()
      pattern P = ()
      
      {-# COMPLETE P #-}
      
      foo P = ()
      ```
      
      This example would previously have caused the checker to warn that
      all cases were not matched even though matching on `P` is sufficient to
      make `foo` covering. With the addition of the pragma, the compiler
      will recognise that matching on `P` alone is enough and not emit
      any warnings.
      
      Reviewers: goldfire, gkaracha, alanz, austin, bgamari
      
      Reviewed By: alanz
      
      Subscribers: lelf, nomeata, gkaracha, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2669
      
      GHC Trac Issues: #8779
      1a3f1eeb
  28. 22 Jan, 2017 1 commit
    • Edward Z. Yang's avatar
      Rewrite Backpack comments on never-exported TyThings. · bbe8956f
      Edward Z. Yang authored
      
      
      Summary:
      While thesing, I realized this part of the implementation
      didn't make very much sense, so I started working on some
      documentation updates to try to make things more explainable.
      
      The new docs are organized around the idea of a
      "never exported TyThing" (a non-implicit TyThing that never
      occurs in the export list of a module).  I also removed
      some outdated information that predated the change of
      ModIface to store Names rather than OccNames.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Reviewers: simonpj, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2989
      bbe8956f
  29. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  30. 18 Jan, 2017 1 commit
  31. 12 Jan, 2017 1 commit
  32. 11 Jan, 2017 3 commits
    • Edward Z. Yang's avatar
      501de268
    • Edward Z. Yang's avatar
      Fix handling of closed type families in Backpack. · f59aad68
      Edward Z. Yang authored
      
      
      Summary:
      A few related problems:
      
      - CoAxioms, like DFuns, are implicit and never exported,
        so we have to make sure we treat them the same way as
        DFuns: in RnModIface we need to rename references to
        them with rnIfaceImplicit and in mergeSignatures we need
        to NOT check them directly for compatibility (the
        test on the type family will do this check for us.)
      
      - But actually, we weren't checking if the axioms WERE
        consistent.  This is because we were forwarding all
        embedded CoAxiom references in the type family TyThing
        to the merged version, but that reference was what
        checkBootDeclM was using as a comparison point.
        This is similar to a problem we saw with DFuns.
      
        To fix this, I refactored the handling of implicit entities in TcIface
        for Backpack.  See Note [The implicit TypeEnv] for the gory details.
        Instead of passing the TypeEnv around explicitly, we stuffed it in
        IfLclEnv.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: bgamari, simonpj, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2928
      f59aad68
    • Edward Z. Yang's avatar
      Revamp Backpack/hs-boot handling of type class signatures. · 5def07fa
      Edward Z. Yang authored
      
      
      Summary:
      A basket of fixes and improvements:
      
      - The permissible things that one can write in a type
        class definition in an hsig file has been reduced
        to encompass the following things:
      
          - Methods
          - Default method signatures (but NOT implementation)
          - MINIMAL pragma
      
        It is no longer necessary nor encouraged to specify
        that a method has a default if it is mentioned in
        a MINIMAL pragma; the MINIMAL pragma is assumed to
        provide the base truth as to what methods need to
        be implemented when writing instances of a type
        class.
      
      - Handling of default method signatures in hsig was
        previously buggy, as these identifiers were not exported,
        so we now treat them similarly to DFuns.
      
      - Default methods are merged, where methods with defaults
        override those without.
      
      - MINIMAL pragmas are merged by ORing together pragmas.
      
      - Matching has been relaxed: a method with a default can
        be used to fill a signature which did not declare the
        method as having a default, and a more relaxed MINIMAL
        pragma can be used (we check if the signature pragma
        implies the final implementation pragma, on the way
        fixing a bug with BooleanFormula.implies, see #13073)
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2925
      
      GHC Trac Issues: #13041
      5def07fa
  33. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      Summary:
      Add prettyprinter tests, which take a file, parse it, pretty print it,
      re-parse the pretty printed version and then compare the original and
      new ASTs (ignoring locations)
      
      Updates haddock submodule to match the AST changes.
      
      There are three issues outstanding
      
      1. Extra parens around a context are not reproduced. This will require an
         AST change and will be done in a separate patch.
      
      2. Currently if an `HsTickPragma` is found, this is not pretty-printed,
         to prevent noise in the output.
      
         I am not sure what the desired behaviour in this case is, so have left
         it as before. Test Ppr047 is marked as expected fail for this.
      
      3. Apart from in a context, the ParsedSource AST keeps all the parens from
         the original source.  Something is happening in the renamer to remove the
         parens around visible type application, causing T12530 to fail, as the
         dumped splice decl is after the renamer.
      
         This needs to be fixed by keeping the parens, but I do not know where they
         are being removed.  I have amended the test to pass, by removing the parens
         in the expected output.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, mpickering, simonpj, bgamari, austin
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2752
      
      GHC Trac Issues: #3384
      499e4382
  34. 29 Nov, 2016 1 commit