1. 02 Nov, 2016 2 commits
    • Simon Peyton Jones's avatar
      Simplify the API for TcHsType.kcHsTyVarBndrs · 7a509660
      Simon Peyton Jones authored
      Pass in a Bool rather than return a funcion!
      
      No change in behaviour.
      7a509660
    • Simon Peyton Jones's avatar
      Get rid of TcTyVars more assiduously · 99689492
      Simon Peyton Jones authored
      * I found a bug in 'generalize' in TcTyClsDecls.kcTyClGroup, where
        the kind variables weren't being turned into proper TyVars, so
        we got (skolem) TcTyVars in TyCons, which shouldn't happen.  Fix
        was easy.
      
      * Similarly TcHsType.kindGeneralizeType wasn't turning the forall'd
        TcTyVars into TyVars.  To achieve this I defined TcHsTyn.zonkSigType.
      
      * All this allowed me to remove awkward and ill-explained bit of
        footwork on DFunIds in Inst.newClsInst
      
      This is just refactoring, but it does make the printout from
      -ddump-deriv make a bit more sense by not grautuitiously cloning
      type variables.  In the display I was seeing
      
         instance C [a_df4] where
            f x = ...a_dx5...
      
      where actually the d_df4 and a_dx5 were the same.
      99689492
  2. 31 Oct, 2016 1 commit
  3. 27 Oct, 2016 1 commit
  4. 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
  5. 20 Oct, 2016 1 commit
    • Edward Z. Yang's avatar
      New story for abstract data types in hsig files. · 518f2895
      Edward Z. Yang authored
      Summary:
      In the old implementation of hsig files, we directly
      reused the implementation of abstract data types from
      hs-boot files.  However, this was WRONG.  Consider the
      following program (an abridged version of bkpfail24):
      
          {-# LANGUAGE GADTs #-}
          unit p where
              signature H1 where
                  data T
              signature H2 where
                  data T
              module M where
                  import qualified H1
                  import qualified H2
      
                  f :: H1.T ~ H2.T => a -> b
                  f x = x
      
      Prior to this patch, M was accepted, because the type
      inference engine concluded that H1.T ~ H2.T does not
      hold (indeed, *presently*, it does not).  However, if
      we subsequently instantiate p with the same module for
      H1 and H2, H1.T ~ H2.T does hold!  Unsound.
      
      The key is that abstract types from signatures need to
      be treated like *skolem variables*, since you can interpret
      a Backpack unit as a record which is universally quantified
      over all of its abstract types, as such (with some fake
      syntax for structural records):
      
          p :: forall t1 t2. { f :: t1 ~ t2 => a -> b }
          p = { f = \x -> x } -- ill-typed
      
      Clearly t1 ~ t2 is not solvable inside p, and also clearly
      it could be true at some point in the future, so we better
      not treat the lambda expression after f as inaccessible.
      
      The fix seems to be simple: do NOT eagerly fail when trying
      to simplify the given constraints.  Instead, treat H1.T ~ H2.T
      as an irreducible constraint (rather than an insoluble
      one); this causes GHC to treat f as accessible--now we will
      typecheck the rest of the function (and correctly fail).
      Per the OutsideIn(X) paper, it's always sound to fail less
      when simplifying givens.
      
      We do NOT apply this fix to hs-boot files, where abstract
      data is also guaranteed to be nominally distinct (since
      it can't be implemented via a reexport or a type synonym.)
      This is a somewhat unnatural state of affairs (there's
      no way to really interpret this in Haskell land) but
      no reason to change behavior.
      
      I deleted "representationally distinct abstract data",
      which is never used anywhere in GHC.
      
      In the process of constructing this fix, I also realized
      our implementation of type synonym matching against abstract
      data was not sufficiently restrictive.  In order for
      a type synonym T to be well-formed type, it must be a
      nullary synonym (i.e., type T :: * -> *, not type T a = ...).
      Furthermore, since we use abstract data when defining
      instances, they must not have any type family applications.
      
      More details in #12680
      
      .  This probably deserves some sort
      of short paper report.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2594
      518f2895
  6. 19 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Test for newtype with unboxed argument · 1f09c16c
      Simon Peyton Jones authored
      Newtypes cannot (currently) have an unboxed argument type.
      But Trac #12729 showed that this was only being checked for
      newtypes in H98 syntax; in GADT snytax they were let through.
      
      This patch moves the test to checkValidDataCon, where it properly
      belongs.
      1f09c16c
  7. 10 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Move zonking out of tcFamTyPats · 76a5477b
      Simon Peyton Jones authored
      In tcFamTyPats we were zonking from the TcType world to the
      Type world, ready to build the results into a CoAxiom (which
      should have no TcType stuff.  But the 'thing_inside' for
      tcFamTyPats also must be zonked, and that zonking must have
      the ZonkEnv from the binders zonked tcFamTyPats.
      
      Ugh.  This caused an assertion failure (with DEBUG on) in
      RaeBlobPost and TypeLevelVec, both in tests/dependent, as
      shown in Trac #12682.  Why it hasn't shown up before now
      is obscure to me.
      
      So I moved the zonking stuff out of tcFamTyPats to its
      three call sites, where we can do it all together. Very
      slightly longer, but much more robust.
      76a5477b
  8. 05 Jul, 2016 1 commit
    • Simon Peyton Jones's avatar
      Check generic-default method for ambiguity · 85aa6ef0
      Simon Peyton Jones authored
      Fixes Trac #7497 and #12151.   In some earlier upheaval I introduced
      a bug in the ambiguity check for genreric-default method.
      
      This patch fixes it.  But in fixing it I realised that the
      sourc-location of any such error message was bogus, so I fixed
      that too, which involved a slightly wider change; see the
      comments with TcMethInfo.
      85aa6ef0
  9. 30 Jun, 2016 1 commit
    • Edward Z. Yang's avatar
      Axe RecFlag on TyCons. · b8b3e30a
      Edward Z. Yang authored
      
      
      Summary:
      This commit removes the information about whether or not
      a TyCon is "recursive", as well as the code responsible
      for calculating this information.
      
      The original trigger for this change was complexity regarding
      how we computed the RecFlag for hs-boot files.  The problem
      is that in order to determine if a TyCon is recursive or
      not, we need to determine if it was defined in an hs-boot
      file (if so, we conservatively assume that it is recursive.)
      
      It turns that doing this is quite tricky.  The "obvious"
      strategy is to typecheck the hi-boot file (since we are
      eventually going to need the typechecked types to check
      if we properly implemented the hi-boot file) and just extract
      the names of all defined TyCons from the ModDetails, but
      this actually does not work well if Names from the hi-boot
      file are being knot-tied via if_rec_types: the "extraction"
      process will force thunks, which will force the typechecking
      process earlier than we have actually defined the types
      locally.
      
      Rather than work around all this trickiness (it certainly
      can be worked around, either by making interface loading
      MORE lazy, or just reading of the set of defined TyCons
      directly from the ModIface), we instead opted to excise
      the source of the problem, the RecFlag.
      
      For one, it is not clear if the RecFlag even makes sense,
      in the presence of higher-orderness:
      
          data T f a = MkT (f a)
      
      T doesn't look recursive, but if we instantiate f with T,
      then it very well is!  It was all very shaky.
      
      So we just don't bother anymore.  This has two user-visible
      implications:
      
      1. is_too_recursive now assumes that all TyCons are
      recursive and will bail out in a way that is still mysterious
      to me if there are too many TyCons.
      
      2. checkRecTc, which is used when stripping newtypes to
      get to representation, also assumes all TyCons are
      recursive, and will stop running if we hit the limit.
      
      The biggest risk for this patch is that we specialize less
      than we used to; however, the codeGen tests still seem to
      be passing.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2360
      b8b3e30a
  10. 25 Jun, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      s/Invisible/Inferred/g s/Visible/Required/g · 5fdb854c
      eir@cis.upenn.edu authored
      This renames VisibilityFlag from
      
      > data VisibilityFlag = Visible | Specified | Invisible
      
      to
      
      > data ArgFlag = Required | Specified | Inferred
      
      The old name was quite confusing, because both Specified
      and Invisible were invisible! The new names are hopefully clearer.
      5fdb854c
  11. 15 Jun, 2016 2 commits
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
      
        - tyConBinders :: [TyConBinder]
      
      The new data types look like this:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
      
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
      
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      
      Some smaller points
      ~~~~~~~~~~~~~~~~~~~
      * Nice new functions
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
      e368f326
    • 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
  12. 13 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Move the constraint-kind validity check · 35c9de7c
      Simon Peyton Jones authored
      For type synonyms, we need to check that if the RHS has
      kind Constraint, then we have -XConstraintKinds.  For
      some reason this was done in checkValidType, but it makes
      more sense to do it in checkValidTyCon.
      
      I can't remember quite why I made this change; maybe it fixes
      a Trac ticket, but if so I forget which.  But it's a modest
      improvement anyway.
      35c9de7c
  13. 19 May, 2016 1 commit
  14. 29 Apr, 2016 1 commit
  15. 20 Apr, 2016 2 commits
    • Simon Peyton Jones's avatar
      Tighten up imports on TcTyClsDecls · cdcf014d
      Simon Peyton Jones authored
      cdcf014d
    • Simon Peyton Jones's avatar
      SCC analysis for instances as well as types/classes · 353d8ae6
      Simon Peyton Jones authored
      This big patch is in pursuit of Trac #11348.
      
      It is largely the work of Alex Veith (thank you!), with some
      follow-up simplification and refactoring from Simon PJ.
      
      The main payload is described in RnSource
        Note [Dependency analysis of type, class, and instance decls]
      which is pretty detailed.
      
      * There is a new data type HsDecls.TyClGroup, for a strongly
        connected component of type/class/instance/role decls.
      
        The hs_instds field of HsGroup disappears, in consequence
      
        This forces some knock-on changes, including a minor
        haddock submodule update
      
      Smaller, weakly-related things
      
      * I found that both the renamer and typechecker were building an
        identical env for RoleAnnots, so I put common code for
        RoleAnnotEnv in RnEnv.
      
      * I found that tcInstDecls1 had very clumsy error handling, so I
        put it together into TcInstDcls.doClsInstErrorChecks
      353d8ae6
  16. 19 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      Tighten checking for associated type instances · 8136a5cb
      Simon Peyton Jones authored
      This patch finishes off Trac #11450.  Following debate on that ticket,
      the patch tightens up the rules for what the instances of an
      associated type can look like.  Now they must match the instance
      header exactly. Eg
      
         class C a b where
          type T a x b
      
      With this class decl, if we have an instance decl
        instance C ty1 ty2 where ...
      then the type instance must look like
           type T ty1 v ty2 = ...
      with exactly
        - 'ty1' for 'a'
        -  'ty2' for 'b', and
        - a variable for 'x'
      
      For example:
      
        instance C [p] Int
          type T [p] y Int = (p,y,y)
      
      Previously we allowed multiple instance equations and now, in effect,
      we don't since they would all overlap.  If you want multiple cases,
      use an auxiliary type family.
      
      This is consistent with the treatment of generic-default instances,
      and the user manual always said "WARNING: this facility (multiple
      instance equations may be withdrawn in the future".
      
      I also improved error messages, and did other minor refactoring.
      8136a5cb
  17. 15 Apr, 2016 1 commit
  18. 11 Apr, 2016 1 commit
    • Rik Steenkamp's avatar
      Fix a closed type family error message · 46e8f199
      Rik Steenkamp authored
      Now we check whether a closed type family's equation is headed with
      the correct type before we kind-check the equation.
      
      Also, instead of "expected only no parameters" we now generate the
      message "expected no parameters".
      
      Fixes #11623.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2089
      
      GHC Trac Issues: #11623
      46e8f199
  19. 25 Mar, 2016 1 commit
    • Simon Peyton Jones's avatar
      A raft of comments about TyBinders · 067335a6
      Simon Peyton Jones authored
      I had a conversation with Richard about TyBinders
      and VisibilityFlags.  This patch adds a lot of comments
      to explain what is going on.  I feel much more secure now.
      
      Richard please check.
      067335a6
  20. 21 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Zonk before calling splitDepVarsOfType. · 5c0c751a
      eir@cis.upenn.edu authored
      It was Utterly Wrong before.
      
      Note to self: Never, ever take the free vars of an unzonked type.
      5c0c751a
    • eir@cis.upenn.edu's avatar
      Track specified/invisible more carefully. · 35e93797
      eir@cis.upenn.edu authored
      In particular, this allows correct tracking of specified/invisible
      for variables in Haskell98 data constructors and in pattern synonyms.
      GADT-syntax constructors are harder, and are left until #11721.
      
      This was all inspired by Simon's comments to my fix for #11512,
      which this subsumes.
      
      Test case: ghci/scripts/TypeAppData
      
      [skip ci]  (The test case fails because of an unrelated problem
      fixed in the next commit.)
      35e93797
  21. 17 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11716. · 3fe87aa0
      eir@cis.upenn.edu authored
      There were several smallish bugs here:
       - We had too small an InScopeSet when rejigging GADT return types.
       - When adding the extra_tvs with a datatype kind signature, we
         were sometimes changing Uniques of an explicitly bound kind var.
       - Using coercionKind in the flattener got the wrong visibility
         for a binder. Now we just zonk to get what we need.
      
      Test case: dependent/should_compile/RaeJobTalk
      3fe87aa0
  22. 15 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Remove redundant anonymiseTyBinders (#11648) · 19be5385
      eir@cis.upenn.edu authored
      This was necessary in an earlier version of the patch for #11648,
      but not in the final version. I forgot to remove it.
      19be5385
    • eir@cis.upenn.edu's avatar
      Fix #11648. · 55577a91
      eir@cis.upenn.edu authored
      We now check that a CUSK is really a CUSK and issue an error if
      it isn't. This also involves more solving and zonking in
      kcHsTyVarBndrs, which was the outright bug reported in #11648.
      
      Test cases: polykinds/T11648{,b}
      
      This updates the haddock submodule.
      
      [skip ci]
      55577a91
  23. 26 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Exclude TyVars from the constraint solver · 7496be5c
      Simon Peyton Jones authored
      There is a general invariant that the constraint solver doesn't see
      TyVars, only TcTyVars.  But when checking the generic-default
      signature of a class, we called checkValidType on the generic-default
      type, which had the class TyVar free. That in turn meant that it wasn't
      considered during flattening, which led to the error reported in
      Trac #11608.
      
      The fix is simple: call checkValidType on the /closed/ type. Easy.
      
      While I was at it, I added a bunch of ASSERTs about the TcTyVar
      invariant.
      7496be5c
  24. 25 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
  25. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      
      This commit also contains a few performance improvements:
      
      * Short-cut equality checking of nullary type syns
      
      * Compare types before kinds in eqType
      
      * INLINE coreViewOneStarKind
      
      * Store tycon binders separately from kinds.
      
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      
      This commit updates the haddock submodule.
      d8c64e86
  26. 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
  27. 17 Feb, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Fix #11313. · a6152159
      eir@cis.upenn.edu authored
      Previously, we looked through synonyms when counting arguments,
      but that's a bit silly.
      a6152159
    • eir@cis.upenn.edu's avatar
      Fix #11246. · 489e6ab5
      eir@cis.upenn.edu authored
      We have to instantiate any invisible arguments to type families
      right away. This is now done in tcTyCon in TcHsType.
      
      testcase: typecheck/should_compile/T11246
      489e6ab5
  28. 10 Feb, 2016 1 commit
  29. 25 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactor validity checking for type/data instances · 746764cc
      Simon Peyton Jones authored
      I found that there was some code duplication going on,
      so I've put more into the shared function checkValidFamPats.
      
      I did some refactoring in checkConsistentFamInst too,
      preparatory to #11450; the error messages change a little
      but no change in behaviour.
      746764cc
  30. 21 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Re-add missing kind generalisation · c572430c
      Simon Peyton Jones authored
      When splitting H98/GADT syntax in ConDecl we lost a key
      kind-generalisation step.
      
      I also renamed tcHsTyVarBndrs to tcExplicitTKBnders, by analogy
      with tcImplicitTkBndrs.
      
      This fixes Trac #11459.
      
      Merge to 8.0.
      c572430c
  31. 19 Jan, 2016 2 commits
    • niteria's avatar
      Check InScopeSet in substTy and provide substTyUnchecked · 9d33adb6
      niteria authored
      This adds sanity checks to `substTy` that implement:
      
      > when calling substTy subst ty it should be the case that the in-scope
      > set in the substitution is a superset of
      > * The free vars of the range of the substitution
      > * The free vars of ty minus the domain of the substitution
      
      and replaces violators with unchecked version. The violators were found
      by running the GHC test suite.
      
      This ensures that I can work on this incrementally and that what I fix won't
      be undone by some other change.
      
      It also includes a couple of fixes that I've already done.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1792
      
      GHC Trac Issues: #11371
      9d33adb6
    • Gabor Greif's avatar
      Typos in comments · 80265c4c
      Gabor Greif authored
      80265c4c
  32. 18 Jan, 2016 2 commits
    • 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
    • Simon Peyton Jones's avatar
      Refactoring on IdInfo and system derived names · ec8a188a
      Simon Peyton Jones authored
      Some modest refactoring, triggered in part by Trac #11051
      
      * Kill off PatSynId, ReflectionId in IdDetails
        They were barely used, and only for pretty-printing
      
      * Add helper function Id.mkExportedVanillaId, and use it
      
      * Polish up OccName.isDerivedOccName, as a predicate for
        definitions generated internally by GHC, which we
        might not want to show to the user.
      
      * Kill off unused OccName.mkDerivedTyConOcc
      
      * Shorten the derived OccNames for newtype and data
        instance axioms
      
      * A bit of related refactoring around newFamInstAxiomName
      ec8a188a