1. 29 Jul, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #14045 by omitting an unnecessary check · d1ef223c
      Richard Eisenberg authored
      Previously, we checked the number of patterns in a data instances
      for all data families whose kind did not end in a kind variable.
      But, of course, undersaturating instances can happen even without
      the kind ending in a kind variable. So I've omitted the arity check.
      Data families aren't as particular about their arity as type families
      are (because data families can be undersaturated). Still, this change
      degrades error messages when instances don't have the right arity;
      now, instead of reporting a simple mismatch in the number of patterns,
      GHC reports kind errors. The new errors are fully accurate, but perhaps
      not as easy to work with. Still, with the new flexibility of allowing
      data family instances with varying numbers of patterns, I don't see
      a better way.
      
      This commit also improves source fidelity in some error messages,
      requiring more changes than really are necessary. But without these
      changes, error messages around mismatched associated instance heads
      were poor.
      
      test cases: indexed-types/should_compile/T14045,
                  indexed-types/should_fail/T14045a
      d1ef223c
  2. 27 Jul, 2017 5 commits
    • Richard Eisenberg's avatar
      Refactor tcInferApps. · 791947db
      Richard Eisenberg authored
      With the changes caused by the fix to #12369, it is now clearer
      how to rewrite tcInferApps and friends. This should change no
      behavior, but it does clean up a nasty corner of the type checker.
      This commit also removes some uses of substTyUnchecked.
      791947db
    • Richard Eisenberg's avatar
      Fix #12369 by being more flexible with data insts · 42392383
      Richard Eisenberg authored
      Previously, a data family's kind had to end in `Type`,
      and data instances had to list all the type patterns for the
      family. However, both of these restrictions were unnecessary:
      
      - A data family's kind can usefully end in a kind variable `k`.
        See examples on #12369.
      
      - A data instance need not list all patterns, much like how a
        GADT-style data declaration need not list all type parameters,
        when a kind signature is in place. This is useful, for example,
        here:
      
          data family Sing (a :: k)
          data instance Sing :: Bool -> Type where ...
      
      This patch also improved a few error messages, as some error
      plumbing had to be moved around.
      
      See new Note [Arity of data families] in FamInstEnv for more
      info.
      
      test case: indexed-types/should_compile/T12369
      42392383
    • Richard Eisenberg's avatar
      Fix #12176 by being a bit more careful instantiating. · 1696dbf4
      Richard Eisenberg authored
      Previously, looking up a TyCon that said "no" to mightBeUnsaturated
      would then instantiate all of its invisible binders. But this is
      wrong for vanilla type synonyms, whose RHS kind might legitimately
      start with invisible binders. So a little more care is taken now,
      only to instantiate those invisible binders that need to be (so that
      the TyCon isn't unsaturated).
      1696dbf4
    • Richard Eisenberg's avatar
      Track visibility in TypeEqOrigin · fb752133
      Richard Eisenberg authored
      A type equality error can arise from a mismatch between
      *invisible* arguments just as easily as from visible arguments.
      But we should really prefer printing out errors from visible
      arguments over invisible ones. Suppose we have a mismatch between
      `Proxy Int` and `Proxy Maybe`. Would you rather get an error
      between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
      so, too.
      
      There is a fair amount of plumbing with this one, but I think
      it's worth it.
      
      This commit introduces a performance regression in test
      perf/compiler/T5631. The cause of the regression is not the
      new visibility stuff, directly: it's due to a change from
      zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
      is nicely optimized (it fuses away), but zipWith3M is not.
      There are other examples of functions that could be made faster,
      so I've posted a separate ticket, #14037, to track these
      improvements. For now, I've accepted the small (6.6%) regression.
      fb752133
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
  3. 19 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13983 by creating a TyConFlavour type, and using it · 6e3c901d
      Ryan Scott authored
      An error message was referring to a type synonym as a datatype.
      Annoyingly, learning that the TyCon over which the error message is
      operating is actually a type synonym was previously impossible, since
      that code only had access to a TcTyCon, which doesn't retain any
      information about what sort of TyCon it is.
      
      To rectify this, I created a new TyConFlavour datatype, intended to
      capture roughly what sort of TyCon we're dealing with. I then performing
      the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and
      propagated this information through to the relevant error message.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13983
      
      Differential Revision: https://phabricator.haskell.org/D3747
      6e3c901d
  4. 06 Jul, 2017 1 commit
  5. 03 Jul, 2017 1 commit
  6. 29 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix lexically-scoped type variables · 3b0e7555
      Simon Peyton Jones authored
      Trac #13881 showed that our handling of lexically scoped type
      variables was way off when we bring into scope a name 'y' for
      a pre-existing type variable 'a', perhaps with an entirely
      different name.
      
      This patch fixes it; see TcHsType
        Note [Pattern signature binders]
      3b0e7555
  7. 28 Jun, 2017 4 commits
  8. 05 Jun, 2017 1 commit
    • Alan Zimmerman's avatar
      Udate hsSyn AST to use Trees that Grow · 8e6ec0fa
      Alan Zimmerman authored
      Summary:
      See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow
      
      This commit prepares the ground for a full extensible AST, by replacing the type
      parameter for the hsSyn data types with a set of indices into type families,
      
          data GhcPs -- ^ Index for GHC parser output
          data GhcRn -- ^ Index for GHC renamer output
          data GhcTc -- ^ Index for GHC typechecker output
      
      These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var`
      
      Where the original name type is required in a polymorphic context, this is
      accessible via the IdP type family, defined as
      
          type family IdP p
          type instance IdP GhcPs = RdrName
          type instance IdP GhcRn = Name
          type instance IdP GhcTc = Id
      
      These types are declared in the new 'hsSyn/HsExtension.hs' module.
      
      To gain a better understanding of the extension mechanism, it has been applied
      to `HsLit` only, also replacing the `SourceText` fields in them with extension
      types.
      
      To preserve extension generality, a type class is introduced to capture the
      `SourceText` interface, which must be honoured by all of the extension points
      which originally had a `SourceText`.  The class is defined as
      
          class HasSourceText a where
            -- Provide setters to mimic existing constructors
            noSourceText  :: a
            sourceText    :: String -> a
      
            setSourceText :: SourceText -> a
            getSourceText :: a -> SourceText
      
      And the constraint is captured in `SourceTextX`, which is a constraint type
      listing all the extension points that make use of the class.
      
      Updating Haddock submodule to match.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari
      
      Subscribers: rwbarton, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3609
      8e6ec0fa
  9. 13 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Remove dead quantifyTyVars · fbb27d77
      Simon Peyton Jones authored
      This patch
      
      * removes a function TcMType.quantifyTyVars
        that was never called
      
      * renames quantifyZonkedTyVars to quantifyTyVars
      
      Plus a few comments.  No functional change at all
      fbb27d77
  10. 31 Mar, 2017 1 commit
    • Ben Gamari's avatar
      Clean up coreView/tcView. · 6575f4b6
      Ben Gamari authored
      In Core, Constraint should be considered fully equal to
      TYPE LiftedRep, in all ways. Accordingly, coreView should
      unwrap Constraint to become TYPE LiftedRep. Of course, this
      would be a disaster in the type checker.
      
      So, where previously we used coreView in both the type checker
      and in Core, we now have coreView and tcView, which differ only
      in their treatment of Constraint.
      
      Historical note: once upon a past, we had tcView distinct from
      coreView. Back then, it was because newtypes were unwrapped in
      Core but not in the type checker. The distinction is back, but
      for a different reason than before.
      
      This had a few knock-on effects:
      
       * The Typeable solver must explicitly handle Constraint to ensure
         that we produce the correct evidence.
      
       * TypeMap now respects the Constraint/Type distinction
      
      Finished by: bgamari
      
      Test Plan: ./validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3316
      6575f4b6
  11. 27 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Simplify the logic for tc_hs_sig_type · 1e06d8b8
      Simon Peyton Jones authored
      In fixing Trac #13337, and introducing solveSomeEqualities,
      Richard introduce the higher-order function tc_hs_sig_type_x,
      with a solver as its argument.
      
      It turned out that there was a much simpler way to do the
      same thing, which this patch implements.  Less code, easier
      to grok.  No change in behaviour though.
      1e06d8b8
  12. 24 Mar, 2017 1 commit
  13. 17 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Remove solveSomeEqualities · 3cfee57a
      Richard Eisenberg authored
      I had thought that it was necessary to solve kind-level equalities
      before validity-checking a type, but I was wrong. This patch simply
      deletes code. Hooray!
      3cfee57a
  14. 14 Mar, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13337. · e0c433c8
      Richard Eisenberg authored
      The big change is the introduction of solveSomeEqualities. This
      is just like solveEqualities, but it doesn't fail if there are unsolved
      equalities when it's all done. Anything unsolved is re-emitted. This
      is appropriate if we are not kind-generalizing, so this new form
      is used when decideKindGeneralizationPlan says not to.
      
      We initially thought that any use of solveEqualities would be tied
      to kind generalization, but this isn't true. For example, we need
      to solveEqualities a bunch in the "tc" pass in TcTyClsDecls (which
      is really desugaring). These equalities are all surely going to be
      soluble (if they weren't the "kc" pass would fail), but we still
      need to solve them again. Perhaps if the "kc" pass produced type-
      checked output that is then desugared, solveEqualities really would
      be tied only to kind generalization.
      
      Updates haddock submodule.
      
      Test Plan: ./validate, typecheck/should_compile/T13337
      
      Reviewers: simonpj, bgamari, austin
      
      Reviewed By: simonpj
      
      Subscribers: RyanGlScott, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3315
      e0c433c8
  15. 06 Mar, 2017 1 commit
  16. 13 Feb, 2017 1 commit
  17. 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
  18. 18 Jan, 2017 1 commit
  19. 10 Jan, 2017 1 commit
  20. 06 Jan, 2017 1 commit
  21. 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
  22. 29 Nov, 2016 1 commit
  23. 25 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Use TyVars in PatSyns · 12eff239
      Simon Peyton Jones authored
      I found that some TcTyVars were lurking in a PatSyn, because
      tc_patsyn_finish was using the TcType -> TcType zonker rather
      than the TcType -> Type zonker.  Eeek.
      
      I fixing this I also tided up function naming a bit (still not
      terrific), and removed the unused TcTyBinder type entirely.
      12eff239
  24. 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
  25. 04 Nov, 2016 1 commit
    • Simon Peyton Jones's avatar
      Remove a debug trace · 7b0ae417
      Simon Peyton Jones authored
      I added this when debugging something else, but in general it doesn't
      work (with -ddump-tc-trace) because of typecking recursive groups of
      TyCons.  So removing it again.
      7b0ae417
  26. 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
  27. 24 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Take account of kinds in promoteTcType · 08ba691a
      Simon Peyton Jones authored
      One of the ASSERT failures in Trac #12762, namely the one for T4439,
      showed that I had not dealt correctly with promoting the kind of
      a type in promoteTcType.
      
      Happily I could fix this by simplifying InferRes (eliminating the
      ir_kind field), so things get better. And the ASSERT is fixed.
      08ba691a
  28. 21 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      A collection of type-inference refactorings. · 3f5673f3
      Simon Peyton Jones authored
      This patch does a raft of useful tidy-ups in the type checker.
      I've been meaning to do this for some time, and finally made
      time to do it en route to ICFP.
      
      1. Modify TcType.ExpType to make a distinct data type,
         InferResult for the Infer case, and consequential
         refactoring.
      
      2. Define a new function TcUnify.fillInferResult, to fill in
         an InferResult. It uses TcMType.promoteTcType to promote
         the type to the level of the InferResult.
         See TcMType Note [Promoting a type]
         This refactoring is in preparation for an improvement
         to typechecking pattern bindings, coming next.
      
         I flirted with an elaborate scheme to give better
         higher rank inference, but it was just too complicated.
         See TcMType Note [Promotion and higher rank types]
      
      3. Add to InferResult a new field ir_inst :: Bool to say
         whether or not the type used to fill in the
         InferResult should be deeply instantiated.  See
         TcUnify Note [Deep instantiation of InferResult].
      
      4. Add a TcLevel to SkolemTvs. This will be useful generally
      
          - it's a fast way to see if the type
            variable escapes when floating (not used yet)
      
          - it provides a good consistency check when updating a
            unification variable (TcMType.writeMetaTyVarRef, the
            level_check_ok check)
      
         I originally had another reason (related to the flirting
         in (2), but I left it in because it seems like a step in
         the right direction.
      
      5. Reduce and simplify the plethora of uExpType,
         tcSubType and related functions in TcUnify.  It was
         such an opaque mess and it's still not great, but it's
         better.
      
      6. Simplify the uo_expected field of TypeEqOrigin.  Richard
         had generatlised it to a ExpType, but it was almost always
         a Check type.  Now it's back to being a plain TcType which
         is much, much easier.
      
      7. Improve error messages by refraining from skolemisation when
         it's clear that there's an error: see
         TcUnify Note [Don't skolemise unnecessarily]
      
      8. Type.isPiTy and isForAllTy seem to be missing a coreView check,
         so I added it
      
      9. Kill off tcs_used_tcvs.  Its purpose is to track the
         givens used by wanted constraints.  For dictionaries etc
         we do that via the free vars of the /bindings/ in the
         implication constraint ic_binds.  But for coercions we
         just do update-in-place in the type, rather than
         generating a binding.  So we need something analogous to
         bindings, to track what coercions we have added.
      
         That was the purpose of tcs_used_tcvs.  But it only
         worked for a /single/ iteration, whereas we may have
         multiple iterations of solving an implication.  Look
         at (the old) 'setImplicationStatus'.  If the constraint
         is unsolved, it just drops the used_tvs on the floor.
         If it becomes solved next time round, we'll pick up
         coercions used in that round, but ignore ones used in
         the first round.
      
         There was an outright bug.  Result = (potentialy) bogus
         unused-constraint errors.  Constructing a case where this
         actually happens seems quite trick so I did not do so.
      
         Solution: expand EvBindsVar to include the (free vars of
         the) coercions, so that the coercions are tracked in
         essentially the same way as the bindings.
      
         This turned out to be much simpler.  Less code, more
         correct.
      
      10. Make the ic_binds field in an implication have type
            ic_binds :: EvBindsVar
          instead of (as previously)
             ic_binds :: Maybe EvBindsVar
          This is notably simpler, and faster to use -- less
          testing of the Maybe.  But in the occaional situation
          where we don't have anywhere to put the bindings, the
          belt-and-braces error check is lost.  So I put it back
          as an ASSERT in 'setImplicationStatus' (see the use of
          'termEvidenceAllowed')
      
      All these changes led to quite bit of error message wibbling
      3f5673f3
  29. 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
  30. 10 Oct, 2016 1 commit
  31. 05 Sep, 2016 1 commit
  32. 21 Jul, 2016 1 commit
    • Ömer Sinan Ağacan's avatar
      Implement unboxed sum primitive type · 714bebff
      Ömer Sinan Ağacan authored
      Summary:
      This patch implements primitive unboxed sum types, as described in
      https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes.
      
      Main changes are:
      
      - Add new syntax for unboxed sums types, terms and patterns. Hidden
        behind `-XUnboxedSums`.
      
      - Add unlifted unboxed sum type constructors and data constructors,
        extend type and pattern checkers and desugarer.
      
      - Add new RuntimeRep for unboxed sums.
      
      - Extend unarise pass to translate unboxed sums to unboxed tuples right
        before code generation.
      
      - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better
        code generation when sum values are involved.
      
      - Add user manual section for unboxed sums.
      
      Some other changes:
      
      - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to
        `MultiValAlt` to be able to use those with both sums and tuples.
      
      - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really
        wrong, given an `Any` `TyCon`, there's no way to tell what its kind
        is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`.
      
      - Fix some bugs on the way: #12375.
      
      Not included in this patch:
      
      - Update Haddock for new the new unboxed sum syntax.
      
      - `TemplateHaskell` support is left as future work.
      
      For reviewers:
      
      - Front-end code is mostly trivial and adapted from unboxed tuple code
        for type checking, pattern checking, renaming, desugaring etc.
      
      - Main translation routines are in `RepType` and `UnariseStg`.
        Documentation in `UnariseStg` should be enough for understanding
        what's going on.
      
      Credits:
      
      - Johan Tibell wrote the initial front-end and interface file
        extensions.
      
      - Simon Peyton Jones reviewed this patch many times, wrote some code,
        and helped with debugging.
      
      Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin,
                 simonmar, hvr, erikd
      
      Reviewed By: simonpj
      
      Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire,
                   thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2259
      714bebff