1. 21 Feb, 2020 1 commit
    • Simon Peyton Jones's avatar
      Re-implement unsafe coercions in terms of unsafe equality proofs · 74ad75e8
      Simon Peyton Jones authored
      (Commit message written by Omer, most of the code is written by Simon
      and Richard)
      See Note [Implementing unsafeCoerce] for how unsafe equality proofs and
      the new unsafeCoerce# are implemented.
      New notes added:
      - [Checking for levity polymorphism] in CoreLint.hs
      - [Implementing unsafeCoerce] in base/Unsafe/Coerce.hs
      - [Patching magic definitions] in Desugar.hs
      - [Wiring in unsafeCoerce#] in Desugar.hs
      Only breaking change in this patch is unsafeCoerce# is not exported from
      GHC.Exts, instead of GHC.Prim.
      Fixes #17443
      Fixes #16893
              Program           Size    Allocs    Instrs     Reads    Writes
                   CS          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  CSD          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                   FS          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                    S          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                   VS          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  VSD          -0.1%      0.0%     -0.0%     -0.0%     -0.1%
                  VSM          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 anna          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 ansi          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 atom          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               awards          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               banner          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
           bernouilli          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         binary-trees          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                boyer          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               boyer2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 bspt          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            cacheprof          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             calendar          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             cichelli          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              circsim          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             clausify          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
        comp_lab_zift          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             compress          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            compress2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
          constraints          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         cryptarithm1          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         cryptarithm2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  cse          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         digits-of-e1          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         digits-of-e2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               dom-lt          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                eliza          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                event          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
          exact-reals          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               exp3_8          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               expert          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
       fannkuch-redux          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                fasta          -0.1%      0.0%     -0.5%     -0.3%     -0.4%
                  fem          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  fft          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 fft2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             fibheaps          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 fish          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                fluid          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               fulsom          -0.1%      0.0%     +0.0%     +0.0%     +0.0%
               gamteb          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  gcd          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
          gen_regexps          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               genfft          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                   gg          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 grep          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               hidden          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  hpg          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  ida          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                infer          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              integer          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            integrate          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         k-nucleotide          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                kahan          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              knights          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               lambda          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
           last-piece          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 lcss          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 life          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 lift          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               linear          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            listcompr          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             listcopy          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             maillist          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               mandel          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              mandel2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 mate          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              minimax          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              mkhprog          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
           multiplier          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               n-body          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             nucleic2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 para          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            paraffins          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               parser          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              parstof          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  pic          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             pidigits          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                power          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               pretty          -0.1%      0.0%     -0.1%     -0.1%     -0.1%
               primes          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            primetest          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               prolog          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               puzzle          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               queens          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              reptile          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
      reverse-complem          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              rewrite          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 rfib          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  rsa          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  scc          -0.1%      0.0%     -0.1%     -0.1%     -0.1%
                sched          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  scs          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               simple          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                solid          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              sorting          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
        spectral-norm          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               sphere          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
               symalg          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  tak          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            transform          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
             treejoin          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            typecheck          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
              veritas          -0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 wang          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
            wave4main          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         wheel-sieve1          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
         wheel-sieve2          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                 x2n1          -0.1%      0.0%     -0.0%     -0.0%     -0.0%
                  Min          -0.1%      0.0%     -0.5%     -0.3%     -0.4%
                  Max          -0.0%      0.0%     +0.0%     +0.0%     +0.0%
       Geometric Mean          -0.1%     -0.0%     -0.0%     -0.0%     -0.0%
      Test changes
      - break006 is marked as broken, see #17833
      - The compiler allocates less when building T14683 (an unsafeCoerce#-
        heavy happy-generated code) on 64-platforms. Allocates more on 32-bit
      - Rest of the increases are tiny amounts (still enough to pass the
        threshold) in micro-benchmarks. I briefly looked at each one in a
        profiling build: most of the increased allocations seem to be because
        of random changes in the generated code.
      Metric Decrease:
      Metric Increase:
      Co-Authored-By: Richard Eisenberg's avatarRichard Eisenberg <rae@cs.brynmawr.edu>
      Co-Authored-By: Ömer Sinan Ağacan's avatarÖmer Sinan Ağacan <omeragacan@gmail.com>
  2. 14 Feb, 2020 1 commit
  3. 06 Jan, 2020 1 commit
  4. 17 Dec, 2019 1 commit
  5. 16 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Break up TcRnTypes, among other modules. · 51fad9e6
      Richard Eisenberg authored
      This introduces three new modules:
       - basicTypes/Predicate.hs describes predicates, moving
         this logic out of Type. Predicates don't really exist
         in Core, and so don't belong in Type.
       - typecheck/TcOrigin.hs describes the origin of constraints
         and types. It was easy to remove from other modules and
         can often be imported instead of other, scarier modules.
       - typecheck/Constraint.hs describes constraints as used in
         the solver. It is taken from TcRnTypes.
      No work other than module splitting is in this patch.
      This is the first step toward homogeneous equality, which will
      rely more strongly on predicates. And homogeneous equality is the
      next step toward a dependently typed core language.
  6. 13 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16411 by making dataConCannotMatch aware of (~~) · 36546a43
      Ryan Scott authored
      The `dataConCannotMatch` function (which powers the
      `-Wpartial-fields` warning, among other things) had special reasoning
      for explicit equality constraints of the form `a ~ b`, but it did
      not extend that reasoning to `a ~~ b` constraints, leading to #16411.
      Easily fixed.
  7. 24 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      See Note [Function types] in TyCoRep.
      There are lots of consequences
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      Other minor stuff
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
  8. 31 Jan, 2019 1 commit
  9. 17 Jan, 2019 1 commit
  10. 29 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      Let's deal with the level-numbers part first:
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
          Finish fix for #14880.
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      Kind inference for types and classes
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
        And candidateQTyVars no longer needs a gbl_tvs argument.
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      Type families
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      * I got rid of kcDataDefn entirely, quite a big function.
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      tcInferApps and friends
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
        Result: tcInferApps is now pretty comprehensible again.
      * I refactored the many function in TcMType that instantiate skolems.
      Smaller things
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      * I killed off quantifyConDecl, instead calling kindGeneralize
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      Some other oddments
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      This patch fixes a raft of bugs, and includes tests for them.
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
  11. 15 Sep, 2018 1 commit
    • Ningning Xie's avatar
      Coercion Quantification · ea5ade34
      Ningning Xie authored
      This patch corresponds to #15497.
      According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2,
       we would like to have coercion quantifications back. This will
      allow us to migrate (~#) to be homogeneous, instead of its current
      heterogeneous definition. This patch is (lots of) plumbing only. There
      should be no user-visible effects.
      An overview of changes:
      - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables,
      but only in *Core*. All relevant functions are updated accordingly.
      - Small changes that should be irrelevant to the main task:
          1. removed dead code `mkTransAppCo` in Coercion
          2. removed out-dated Note Computing a coercion kind and
             roles in Coercion
          3. Added `Eq4` in Note Respecting definitional equality in
             TyCoRep, and updated `mkCastTy` accordingly.
          4. Various updates and corrections of notes and typos.
      - Haddock submodule needs to be changed too.
      This work was completed mostly during Ningning Xie's Google Summer
      of Code, sponsored by Google. It was advised by Richard Eisenberg,
      supported by NSF grant 1704041.
      Test Plan: ./validate
      Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar
      Subscribers: RyanGlScott, monoidal, rwbarton, carter
      GHC Trac Issues: #15497
      Differential Revision: https://phabricator.haskell.org/D5054
  12. 01 Aug, 2018 1 commit
    • Richard Eisenberg's avatar
      Remove the type-checking knot. · f8618a9b
      Richard Eisenberg authored
      Bug #15380 hangs because a knot-tied TyCon ended up in a kind.
      Looking at the code in tcInferApps, I'm amazed this hasn't happened
      before! I couldn't think of a good way to fix it (with dependent
      types, we can't really keep types out of kinds, after all), so
      I just went ahead and removed the knot.
      This was remarkably easy to do. In tcTyVar, when we find a TcTyCon,
      just use it. (Previously, we looked up the knot-tied TyCon and used
      that.) Then, during the final zonk, replace TcTyCons with the real,
      full-blooded TyCons in the global environment. It's all very easy.
      The new bit is explained in the existing
      Note [Type checking recursive type and class declarations]
      in TcTyClsDecls.
      Naturally, I removed various references to the knot and the
      zonkTcTypeInKnot (and related) functions. Now, we can print types
      during type checking with abandon!
      NB: There is a teensy error message regression with this patch,
      around the ordering of quantified type variables. This ordering
      problem is fixed (I believe) with the patch for #14880. The ordering
      affects only internal variables that cannot be instantiated with
      any kind of visible type application.
      There is also a teensy regression around the printing of types
      in TH splices. I think this is really a TH bug and will file
      Test case: dependent/should_fail/T15380
  13. 15 Jul, 2018 1 commit
    • Richard Eisenberg's avatar
      Move check for dcUserTyVarBinders invariant · fe0fa63e
      Richard Eisenberg authored
      Previously, this check was done in mkDataCon. But this
      sometimes caused assertion failures if an invalid data
      con was made. I've moved the check to checkValidDataCon,
      where we can be sure the datacon is otherwise valid first.
  14. 18 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Two small refactorings · 850ae8c5
      Simon Peyton Jones authored
      * Define Type.substTyVarBndrs, and use it
      * Rename substTyVarBndrCallback to substTyVarBndrUsing,
        and other analogous higher order functions.  I kept
        stumbling over the name.
  15. 14 Jun, 2018 1 commit
    • Vladislav Zavialov's avatar
      Embrace -XTypeInType, add -XStarIsType · d650729f
      Vladislav Zavialov authored
      Implement the "Embrace Type :: Type" GHC proposal,
      GHC 8.0 included a major change to GHC's type system: the Type :: Type
      axiom. Though casual users were protected from this by hiding its
      features behind the -XTypeInType extension, all programs written in GHC
      8+ have the axiom behind the scenes. In order to preserve backward
      compatibility, various legacy features were left unchanged. For example,
      with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
      Now these restrictions are lifted and -XTypeInType becomes a redundant
      flag that will be eventually deprecated.
      * Incorporate the features currently in -XTypeInType into the
        -XPolyKinds and -XDataKinds extensions.
      * Introduce a new extension -XStarIsType to control how to parse * in
        code and whether to print it in error messages.
      Test Plan: Validate
      Reviewers: goldfire, hvr, bgamari, alanz, simonpj
      Reviewed By: goldfire, simonpj
      Subscribers: rwbarton, thomie, mpickering, carter
      GHC Trac Issues: #15195
      Differential Revision: https://phabricator.haskell.org/D4748
  16. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
      Fixes #14066 #14749
      Test cases: dependent/should_compile/{T14066a,T14749},
  17. 10 Jan, 2018 1 commit
    • niteria's avatar
      Lift constructor tag allocation out of a loop · dbdf77d9
      niteria authored
      Before this change, for each constructor that we want
      to allocate a tag for we would traverse a list of all
      the constructors in a datatype to determine which tag
      a constructor should get.
      This is obviously quadratic and for datatypes with 10k
      constructors it actually makes a big difference.
      This change implements the plan outlined by @simonpj in
      which is basically about using a map and constructing it outside the
      One place where things got a bit awkward was TysWiredIn.hs,
      it would have been possible to just assign the tags by hand, but
      that seemed error-prone to me, so I decided to go through a map
      there as well.
      Test Plan:
      On a file with 10k constructors
         8,130,522,344 bytes allocated in the heap
        Total   time    3.682s  (  3.920s elapsed)
         4,133,478,744 bytes allocated in the heap
        Total   time    2.509s  (  2.750s elapsed)
      Reviewers: simonpj, bgamari
      Reviewed By: simonpj
      Subscribers: goldfire, rwbarton, thomie, simonmar, carter, simonpj
      GHC Trac Issues: #14657
      Differential Revision: https://phabricator.haskell.org/D4289
  18. 07 Oct, 2017 1 commit
    • Ryan Scott's avatar
      Incorporate changes from #11721 into Template Haskell · 341d3a78
      Ryan Scott authored
      #11721 changed the order of type variables in GADT
      constructor type signatures, but these changes weren't reflected in
      Template Haskell reification of GADTs. Let's do that.
      Along the way, I:
      * noticed that the `T13885` test was claiming to test TH reification
        of GADTs, but the reified data type wasn't actually a GADT! Since
        this patch touches that part of the codebase, I decided to fix
      * incorporated some feedback from @simonpj in
        https://phabricator.haskell.org/D3687#113566. (These changes alone
        don't account for any different in behavior.)
      Test Plan: make test TEST=T11721_TH
      Reviewers: goldfire, austin, bgamari, simonpj
      Reviewed By: goldfire, bgamari, simonpj
      Subscribers: rwbarton, thomie, simonpj
      GHC Trac Issues: #11721
      Differential Revision: https://phabricator.haskell.org/D4070
  19. 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:
      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:
      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:
      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
  20. 29 Sep, 2017 1 commit
  21. 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
      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
  22. 01 Aug, 2017 1 commit
  23. 31 Jul, 2017 1 commit
  24. 29 Jun, 2017 1 commit
  25. 28 Jun, 2017 1 commit
  26. 02 Jun, 2017 1 commit
    • Ryan Scott's avatar
      Use lengthIs and friends in more places · a786b136
      Ryan Scott authored
      While investigating #12545, I discovered several places in the code
      that performed length-checks like so:
      length ts == 4
      This is not ideal, since the length of `ts` could be much longer than 4,
      and we'd be doing way more work than necessary! There are already a slew
      of helper functions in `Util` such as `lengthIs` that are designed to do
      this efficiently, so I found every place where they ought to be used and
      did just that. I also defined a couple more utility functions for list
      length that were common patterns (e.g., `ltLength`).
      Test Plan: ./validate
      Reviewers: austin, hvr, goldfire, bgamari, simonmar
      Reviewed By: bgamari, simonmar
      Subscribers: goldfire, rwbarton, thomie
      Differential Revision: https://phabricator.haskell.org/D3622
  27. 12 May, 2017 1 commit
  28. 28 Apr, 2017 1 commit
  29. 10 Mar, 2017 1 commit
  30. 01 Mar, 2017 1 commit
    • David Feuer's avatar
      Upgrade UniqSet to a newtype · cbe569a5
      David Feuer authored
      The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet`
      has a key invariant `UniqFM` does not. For example, `fmap` over
      `UniqSet` will generally produce nonsense.
      * Upgrade `UniqSet` from a type synonym to a newtype.
      * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`.
      * Use cached unique in `tyConsOfType` by replacing
        `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`.
      Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari
      Reviewed By: niteria
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D3146
  31. 14 Feb, 2017 1 commit
    • Adam Gundry's avatar
      Implement HasField constraint solving and modify OverloadedLabels · da493897
      Adam Gundry authored
      This implements automatic constraint solving for the new HasField class
      and modifies the existing OverloadedLabels extension, as described in
      the GHC proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/6). Per the current
      form of the proposal, it does *not* currently introduce a separate
      `OverloadedRecordFields` extension.
      This replaces D1687.
      The users guide documentation still needs to be written, but I'll do
      that after the implementation is merged, in case there are further
      design changes.
      Test Plan: new and modified tests in overloadedrecflds
      Reviewers: simonpj, goldfire, dfeuer, bgamari, austin, hvr
      Reviewed By: bgamari
      Subscribers: maninalift, dfeuer, ysangkok, thomie, mpickering
      Differential Revision: https://phabricator.haskell.org/D2708
  32. 31 Jan, 2017 1 commit
  33. 26 Jan, 2017 1 commit
  34. 07 Dec, 2016 1 commit
    • Alan Zimmerman's avatar
      Add HsSyn prettyprinter tests · 499e4382
      Alan Zimmerman authored
      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
  35. 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:
           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.
  36. 05 Aug, 2016 1 commit
  37. 21 Jul, 2016 2 commits
    • Simon Peyton Jones's avatar
    • Ömer Sinan Ağacan's avatar
      Implement unboxed sum primitive type · 714bebff
      Ömer Sinan Ağacan authored
      This patch implements primitive unboxed sum types, as described in
      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.
      - Johan Tibell wrote the initial front-end and interface file
      - 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
  38. 30 Jun, 2016 2 commits
    • Edward Z. Yang's avatar
      Axe RecFlag on TyCons. · b8b3e30a
      Edward Z. Yang authored
      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
      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
      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
    • niteria's avatar
      Delete Ord Unique · fb6e2c7f
      niteria authored
      Ord Unique can be a source of invisible, accidental
      nondeterminism as explained in Note [No Ord for Unique].
      This removes it, leaving a note with rationale.
      It's unfortunate that I had to write Ord instances for
      codegen data structures by hand, but I believe that it's a
      right trade-off here.
      Test Plan: ./validate
      Reviewers: simonmar, austin, bgamari
      Reviewed By: simonmar
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2370
      GHC Trac Issues: #4012