1. 14 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refactor coercion holes · b586f77b
      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.
      
      (cherry picked from commit a492af06)
      b586f77b
  2. 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
  3. 09 Nov, 2017 1 commit
  4. 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
  5. 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
  6. 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
  7. 28 Jul, 2017 1 commit
  8. 27 Jul, 2017 1 commit
  9. 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
  10. 20 Jul, 2017 1 commit
  11. 09 Mar, 2017 1 commit
  12. 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
  13. 03 Mar, 2017 2 commits
  14. 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
  15. 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
  16. 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
  17. 24 Feb, 2017 1 commit
  18. 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
  19. 02 Feb, 2017 1 commit
  20. 01 Feb, 2017 1 commit
  21. 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
  22. 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
  23. 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
  24. 18 Jan, 2017 1 commit
  25. 12 Jan, 2017 1 commit
  26. 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
  27. 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
  28. 29 Nov, 2016 1 commit
  29. 25 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve pretty-printing of types · 5f349fe2
      Simon Peyton Jones authored
      In this commit
         commit 6c0f10fa
         Author: Ben Gamari <bgamari.foss@gmail.com>
         Date:   Sun Nov 13 16:17:37 2016 -0500
      
          Kill Type pretty-printer
      
      we switched to pretty-printing a type by converting it to an
      IfaceType and pretty printing that.  Very good.
      
      This patch fixes two things
      
      * The new story is terrible for debug-printing with -ddump-tc-trace,
        because all the extra info in an open type was discarded ty the
        conversion to IfaceType.
      
        This patch adds IfaceTcTyVar to IfaceType, to carry a TcTyVar in
        debug situations.  Quite an easy change, happily.  These things
        never show up in interface files.
      
      * Now that we are going via IfaceType, it's essential to tidy before
        converting; otherwise
           forall k_23 k_34. blah
        is printed as
           forall k k. blah
        which is very unhelpful.  Again this only shows up in debug
        printing.
      5f349fe2
  30. 13 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Kill Type pretty-printer · 6c0f10fa
      Ben Gamari authored
      Here we consolidate the pretty-printing logic for types in IfaceType. We
      need IfaceType regardless and the printer for Type can be implemented in
      terms of that for IfaceType. See #11660.
      
      Note that this is very much a work-in-progress. Namely I still have yet
      to ponder how to ease the hs-boot file situation, still need to rip out
      more dead code, need to move some of the special cases for, e.g., `*` to
      the IfaceType printer, and need to get it to validate. That being said,
      it comes close to validating as-is.
      
      Test Plan: Validate
      
      Reviewers: goldfire, austin
      
      Subscribers: goldfire, thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D2528
      
      GHC Trac Issues: #11660
      6c0f10fa
  31. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactor occurrence-check logic · 9417e579
      Simon Peyton Jones authored
      This patch does two related things
      
      * Combines the occurrence-check logic in the on-the-fly unifier with
        that in the constraint solver.  They are both doing the same job,
        after all.  The resulting code is now in TcUnify:
           metaTyVarUpdateOK
           occCheckExpand
           occCheckForErrors (called in TcErrors)
      
      * In doing this I disovered checking for family-free-ness and foralls
        can be unnecessarily inefficient, because it expands type synonyms.
        It's easy just to cache this info in the type syononym TyCon, which
        I am now doing.
      9417e579
  32. 20 Oct, 2016 1 commit
  33. 14 Oct, 2016 2 commits
    • Ben Gamari's avatar
      Improve find_lbl panic message · aa06883c
      Ben Gamari authored
      aa06883c
    • Ben Gamari's avatar
      Clean up handling of known-key Names in interface files · 34d933d6
      Ben Gamari authored
      Previously BinIface had some dedicated logic for handling tuple names in
      the symbol table. As it turns out, this logic was essentially dead code
      as it was superceded by the special handling of known-key things. Here
      we cull the tuple code-path and use the known-key codepath for all
      tuple-ish things.
      
      This had a surprising number of knock-on effects,
      
       * constraint tuple datacons had to be made known-key (previously they
         were not)
      
       * IfaceTopBndr was changed from being a synonym of OccName to a
         synonym of Name (since we now need to be able to deserialize Names
         directly from interface files)
      
       * the change to IfaceTopBndr complicated fingerprinting, since we need
         to ensure that we don't go looking for the fingerprint of the thing
         we are currently fingerprinting in the fingerprint environment (see
         notes in MkIface). Handling this required distinguishing between
         binding and non-binding Name occurrences in the Binary serializers.
      
       * the original name cache logic which previously lived in IfaceEnv has
         been moved to a new NameCache module
      
       * I ripped tuples and sums out of knownKeyNames since they introduce a
         very large number of entries. During interface file deserialization
         we use static functions (defined in the new KnownUniques module) to
         map from a Unique to a known-key Name (the Unique better correspond
         to a known-key name!) When we need to do an original name cache
         lookup we rely on the parser implemented in isBuiltInOcc_maybe.
      
       * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames.
      
       * Lots of comments were sprinkled about describing the new scheme.
      
      Updates haddock submodule.
      
      Test Plan: Validate
      
      Reviewers: niteria, simonpj, austin, hvr
      
      Reviewed By: simonpj
      
      Subscribers: simonmar, niteria, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2467
      
      GHC Trac Issues: #12532, #12415
      34d933d6
  34. 08 Oct, 2016 1 commit