1. 23 Jan, 2017 1 commit
  2. 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
      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
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      * 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
      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
      * 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
      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
      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
      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
      * 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:
      * Fixed tickets:
      * 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.
  3. 17 Dec, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Reshuffle levity polymorphism checks. · 8906e7b7
      eir@cis.upenn.edu authored
      Previously, GHC checked for bad levity polymorphism to the left of all
      arrows in data constructors. This was wrong, as reported in #12911
      (where an example is also shown). The solution is to check each
      individual argument for bad levity polymorphism.  Thus the check has
      been moved from TcValidity to TcTyClsDecls.
      A similar situation exists with pattern synonyms, also fixed here.
      This patch also nabs #12819 while I was in town.
      Test cases: typecheck/should_compile/T12911, patsyn/should_fail/T12819
      Test Plan: ./validate
      Reviewers: simonpj, austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2783
      GHC Trac Issues: #12819, #12911
  4. 20 Jul, 2016 1 commit
    • Ömer Sinan Ağacan's avatar
      Support SCC pragmas in declaration context · 98b2c508
      Ömer Sinan Ağacan authored
      Not having SCCs at the top level is becoming annoying real quick. For
      simplest cases, it's possible to do this transformation:
          f x y = ...
          f = {-# SCC f #-} \x y -> ...
      However, it doesn't work when there's a `where` clause:
          f x y = <t is in scope>
            where t = ...
          f = {-# SCC f #-} \x y -> <t is out of scope>
            where t = ...
      Or when we have a "equation style" definition:
          f (C1 ...) = ...
          f (C2 ...) = ...
          f (C3 ...) = ...
      (usual solution is to rename `f` to `f'` and define a new `f` with a
      This patch implements support for SCC annotations in declaration
      contexts. This is now a valid program:
          f x y = ...
              g z = ...
              {-# SCC g #-}
          {-# SCC f #-}
      Test Plan: This passes slow validate (no new failures added).
      Reviewers: goldfire, mpickering, austin, bgamari, simonmar
      Reviewed By: bgamari, simonmar
      Subscribers: simonmar, thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D2407
  5. 01 Jul, 2016 1 commit
  6. 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
      > data ArgFlag = Required | Specified | Inferred
      The old name was quite confusing, because both Specified
      and Invisible were invisible! The new names are hopefully clearer.
  7. 21 Jun, 2016 1 commit
  8. 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:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
           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
        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.
    • 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
  9. 13 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve typechecking of let-bindings · 15b9bf4b
      Simon Peyton Jones authored
      This major commit was initially triggered by #11339, but it spiraled
      into a major review of the way in which type signatures for bindings
      are handled, especially partial type signatures.  On the way I fixed a
      number of other bugs, namely
      The main change is that I completely reorganised the way in which type
      signatures in bindings are handled. The new story is in TcSigs
      Note [Overview of type signatures].  Some specific:
      * Changes in the data types for signatures in TcRnTypes:
        TcIdSigInfo and new TcIdSigInst
      * New module TcSigs deals with typechecking type signatures
        and pragmas. It contains code mostly moved from TcBinds,
        which is already too big
      * HsTypes: I swapped the nesting of HsWildCardBndrs
        and HsImplicitBndsrs, so that the wildcards are on the
        oustide not the insidde in a LHsSigWcType.  This is just
        a matter of convenient, nothing deep.
      There are a host of other changes as knock-on effects, and
      it all took FAR longer than I anticipated :-).  But it is
      a significant improvement, I think.
      Lots of error messages changed slightly, some just variants but
      some modest improvements.
      New tests
      * typecheck/should_compile
          * SigTyVars: a scoped-tyvar test
          * ExPat, ExPatFail: existential pattern bindings
          * T12069
          * T11700
          * T11339
      * partial-sigs/should_compile
          * T12033
          * T11339a
          * T11670
      One thing to check:
      * Small change to output from ghc-api/landmines.
        Need to check with Alan Zimmerman