1. 28 Nov, 2019 1 commit
  2. 13 Nov, 2019 1 commit
    • Ben Gamari's avatar
      Ensure that coreView/tcView are able to inline · 2d4f9ad8
      Ben Gamari authored
      Previously an import cycle between Type and TyCoRep meant that several
      functions in TyCoRep ended up SOURCE import coreView. This is quite
      unfortunate as coreView is intended to be fused into a larger pattern
      match and not incur an extra call.
      
      Fix this with a bit of restructuring:
      
       * Move the functions in `TyCoRep` which depend upon things in `Type`
         into `Type`
       * Fold contents of `Kind` into `Type` and turn `Kind` into a simple
         wrapper re-exporting kind-ish things from `Type`
       * Clean up the redundant imports that popped up as a result
      
      Closes #17441.
      
      Metric Decrease:
          T4334
      2d4f9ad8
  3. 10 Nov, 2019 1 commit
    • Richard Eisenberg's avatar
      Fix #17405 by not checking imported equations · 55ca1085
      Richard Eisenberg authored
      Previously, we checked all imported type family equations
      for injectivity. This is very silly. Now, we check only
      for conflicts.
      
      Before I could even imagine doing the fix, I needed to untangle
      several functions that were (in my opinion) overly complicated.
      It's still not quite as perfect as I'd like, but it's good enough
      for now.
      
      Test case: typecheck/should_compile/T17405
      55ca1085
  4. 29 Oct, 2019 1 commit
  5. 23 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Implement a coverage checker for injectivity · 1cd3fa29
      Richard Eisenberg authored
      This fixes #16512.
      
      There are lots of parts of this patch:
      
      * The main payload is in FamInst. See
      Note [Coverage condition for injective type families] there
      for the overview. But it doesn't fix the bug.
      
      * We now bump the reduction depth every time we discharge
      a CFunEqCan. See Note [Flatten when discharging CFunEqCan]
      in TcInteract.
      
      * Exploration of this revealed a new, easy to maintain invariant
      for CTyEqCans. See Note [Almost function-free] in TcRnTypes.
      
      * We also realized that type inference for injectivity was a
      bit incomplete. This means we exchanged lookupFlattenTyVar for
      rewriteTyVar. See Note [rewriteTyVar] in TcFlatten. The new
      function is monadic while the previous one was pure, necessitating
      some faff in TcInteract. Nothing too bad.
      
      * zonkCt did not maintain invariants on CTyEqCan. It's not worth
      the bother doing so, so we just transmute CTyEqCans to
      CNonCanonicals.
      
      * The pure unifier was finding the fixpoint of the returned
      substitution, even when doing one-way matching (in tcUnifyTysWithTFs).
      Fixed now.
      
      Test cases: typecheck/should_fail/T16512{a,b}
      1cd3fa29
  6. 01 Oct, 2019 1 commit
    • Ömer Sinan Ağacan's avatar
      Refactor iface file generation: · f3cb8c7c
      Ömer Sinan Ağacan authored
      This commit refactors interface file generation to allow information
      from the later passed (NCG, STG) to be stored in interface files.
      
      We achieve this by splitting interface file generation into two parts:
      * Partial interfaces, built based on the result of the core pipeline
      * A fully instantiated interface, which also contains the final
      fingerprints and can optionally contain information produced by the backend.
      
      This change is required by !1304 and !1530.
      
      -dynamic-too handling is refactored too: previously when generating code
      we'd branch on -dynamic-too *before* code generation, but now we do it
      after.
      
      (Original code written by @AndreasK in !1530)
      
      Performance
      ~~~~~~~~~~~
      
      Before this patch interface files where created and immediately flushed
      to disk which made space leaks impossible.
      With this change we instead use NFData to force all iface related data
      structures to avoid space leaks.
      
      In the process of refactoring it was discovered that the code in the
      ToIface Module allocated a lot of thunks which were immediately forced
      when writing/forcing the interface file. So we made this module more
      strict to avoid creating many of those thunks.
      
      Bottom line is that allocations go down by about ~0.1% compared to
      master.
      Residency is not meaningfully different after this patch.
      Runtime was not benchmarked.
      Co-Authored-By: Andreas Klebinger's avatarAndreas Klebinger <klebinger.andreas@gmx.at>
      Co-Authored-By: Ömer Sinan Ağacan's avatarÖmer Sinan Ağacan <omer@well-typed.com>
      f3cb8c7c
  7. 28 May, 2019 1 commit
  8. 24 Feb, 2019 2 commits
    • 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
        IfaceFunTy.
      
      * 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
      6cce36f8
    • Simon Peyton Jones's avatar
      Remove bogus assertion · ac34e784
      Simon Peyton Jones authored
      Remove a bogus assertion in FamInst.newFamInst
      (There is a comment to explain.)
      
      This fixes Trac #16112.
      ac34e784
  9. 23 Jan, 2019 1 commit
  10. 21 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix treatment of hi-boot files and dfuns · a57d5c4d
      Simon Peyton Jones authored
      Trac #16038 exposed the fact that TcRnDriver.checkHiBootIface
      was creating a binding, in the module being compiled, for
         $fxBlah = $fBlah
      
       but $fxBlah was a /GlobalId/. But all bindings should be for
       /LocalIds/ else dependency analysis goes down the tubes.
      
      * I added a CoreLint check that an occurrence of a GlobalId
        is not bound by an binding of a LocalId.  (There is already
        a binding-site check that no binding binds a GlobalId.)
      
      * I refactored (and actually signficantly simplified) the
        tricky code for dfuns in checkHiBootIface to ensure that
        we get LocalIds for those boot-dfuns.
      
      Alas, I then got "duplicate instance" messages when compiling
      HsExpr. It turns out that this is a long-standing, but extremely
      delicate, bug: even before this patch, if you compile HsExpr
      with -ddump-tc-trace, you get "duplicate instance". Without
      -ddump-tc-trace, it's OK.  What a mess!
      
      The reason for the duplicate-instance is now explained in
      Note [Loading your own hi-boot file] in LoadIface.  I fixed
      it by a Gross Hack in LoadIface.loadInterface. This is at
      least no worse than before.
      
      But there should be a better way. I have opened #16081 for this.
      a57d5c4d
  11. 03 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Introduce tcTypeKind, and use it · 03d48526
      Simon Peyton Jones authored
      In the type checker Constraint and * are distinct; and the function
      that takes the kind of a type should respect that distinction
      (Trac #15971).
      
      This patch implements the change:
      
      * Introduce Type.tcTypeKind, and use it throughout the type
        inference engine
      
      * Add new Note [Kinding rules for types] for the kinding
        rules, especially for foralls.
      
      * Redefine
          isPredTy ty = tcIsConstraintKind (tcTypeKind ty)
        (it had a much more complicated definition before)
      
      Some miscellaneous refactoring
      
      * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp,
        in favour of TyCoRep.kindRep, kindRep_maybe
      
      * Rename Type.getRuntimeRepFromKind_maybe
        to getRuntimeRep_maybe
      
      I did some spot-checks on compiler perf, and it really doesn't
      budge (as expected).
      03d48526
  12. 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
      engine.
      
      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.
      
      Quantification
      ~~~~~~~~~~~~~~
      * 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
        directly.
      
      * 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
      2257a86d
  13. 22 Nov, 2018 1 commit
    • Ryan Scott's avatar
      Overhaul -fprint-explicit-kinds to use VKA · f5d20838
      Ryan Scott authored
      This patch changes the behavior of `-fprint-explicit-kinds`
      so that it displays kind argument using visible kind application.
      In other words, the flag now:
      
      1. Prints instantiations of specified variables with `@(...)`.
      2. Prints instantiations of inferred variables with `@{...}`.
      
      In addition, this patch removes the `Use -fprint-explicit-kinds to
      see the kind arguments` error message that often arises when a type
      mismatch occurs due to different kinds. Instead, whenever there is a
      kind mismatch, we now enable the `-fprint-explicit-kinds` flag
      locally to help cue to the programmer where the error lies.
      (See `Note [Kind arguments in error messages]` in `TcErrors`.)
      As a result, these funny `@{...}` things can now appear to the user
      even without turning on the `-fprint-explicit-kinds` flag explicitly,
      so I took the liberty of documenting them in the users' guide.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15871
      
      Differential Revision: https://phabricator.haskell.org/D5314
      f5d20838
  14. 01 Nov, 2018 1 commit
    • Richard Eisenberg's avatar
      Don't lint erroneous programs. · 1f72a1c8
      Richard Eisenberg authored
      newFamInst lints its types. This is good. But it's not so good
      when there have been errors and thus recovery tycons are about.
      So we now don't.
      
      Fixes #15796.
      
      Test case: typecheck/should_fail/T15796
      1f72a1c8
  15. 29 Oct, 2018 1 commit
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      
      As a bonus, we now have more control over the ordering of such
      skolems.
      
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      
      Test cases: dependent/should_fail/T14880{,-2},
                  dependent/should_fail/T15743[cd]
                  dependent/should_compile/T15743{,e}
                  ghci/scripts/T15743b
                  polykinds/T15592
                  dependent/should_fail/T15591[bc]
                  ghci/scripts/T15591
      5e45ad10
  16. 15 Oct, 2018 1 commit
  17. 01 Oct, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15637 by using VTA more in GND · 309438e9
      Ryan Scott authored
      Summary:
      The code that GND was generating before could crumple over
      if it derived an instance for a class with an ambiguous type variable
      in the class head, such as the example in #15637. The solution is
      straightforward: simply instantiate all variables bound by the class
      head explicitly using visible type application, which will nip any
      ambiguity in the bud.
      
      Test Plan: make test TEST=T15637
      
      Reviewers: bgamari, simonpj, goldfire
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15637
      
      Differential Revision: https://phabricator.haskell.org/D5148
      309438e9
  18. 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
      separately.
      
      Test case: dependent/should_fail/T15380
      f8618a9b
  19. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  20. 27 Apr, 2018 2 commits
    • Simon Peyton Jones's avatar
      Better linting for types · 6da5b877
      Simon Peyton Jones authored
      Trac #15057 described deficiencies in the linting for types
      involving type synonyms.  This patch fixes an earlier attempt.
      
      The moving parts are desrcribed in
        Note [Linting type synonym applications]
      
      Not a big deal.
      6da5b877
    • Simon Peyton Jones's avatar
      Refactor tcExtendLocalFamInst a bit · 0c01224b
      Simon Peyton Jones authored
      This patch just pulls out FamInst.loadDependentFamInstModules
      as a separate function, and adds better comments.
      
      Provoked by Trac #14759, comment:10.
      0c01224b
  21. 20 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Lint types in newFamInst · 257c13d8
      Ryan Scott authored
      We weren't linting the types used in `newFamInst`, which
      might have been why #15012 went undiscovered for so long. Let's fix
      that.
      
      One has to be surprisingly careful with expanding type synonyms in
      `lintType`, since in the offending program (simplified):
      
      ```lang=haskell
      type FakeOut a = Int
      
      type family TF a
      type instance TF Int = FakeOut a
      ```
      
      If one expands type synonyms, then `FakeOut a` will expand to
      `Int`, which masks the issue (that `a` is unbound). I added an
      extra Lint flag to configure whether type synonyms should be
      expanded or not in Lint, and disabled this when calling `lintTypes`
      from `newFamInst`.
      
      As evidence that this works, I ran it on the offending program
      from #15012, and voilà:
      
      ```
      $ ghc3/inplace/bin/ghc-stage2 Bug.hs -dcore-lint
      [1 of 1] Compiling Foo              ( Bug.hs, Bug.o )
      ghc-stage2: panic! (the 'impossible' happened)
        (GHC version 8.5.20180417 for x86_64-unknown-linux):
              Core Lint error
        <no location info>: warning:
            In the type ‘... (Rec0 (FakeOut b_a1Qt))))’
            @ b_a1Qt is out of scope
      ```
      
      Test Plan: make test TEST=T15057
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15057
      
      Differential Revision: https://phabricator.haskell.org/D4611
      257c13d8
  22. 19 Dec, 2017 1 commit
  23. 01 Dec, 2017 1 commit
    • Edward Z. Yang's avatar
      Make use of boot TyThings during typechecking. · 69987720
      Edward Z. Yang authored
      Summary:
      Suppose that you are typechecking A.hs, which transitively imports,
      via B.hs, A.hs-boot.  When we poke on B.hs and discover that it
      has a reference to a type from A, what TyThing should we wire
      it up with?  Clearly, if we have already typechecked A, we
      should use the most up-to-date TyThing: the one we freshly
      generated when we typechecked A.  But what if we haven't typechecked
      it yet?
      
      For the longest time, GHC adopted the policy that this was
      *an error condition*; that you MUST NEVER poke on B.hs's reference
      to a thing defined in A.hs until A.hs has gotten around to checking
      this.  However, actually ensuring this is the case has proven
      to be a bug farm.  The problem was especially poignant with
      type family consistency checks, which eagerly happen before
      any typechecking takes place.
      
      This patch takes a different strategy: if we ever try to access
      an entity from A which doesn't exist, we just fall back on the
      definition of A from the hs-boot file.  This means that you may
      end up with a mix of A.hs and A.hs-boot TyThings during the
      course of typechecking.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@fb.com>
      
      Test Plan: validate
      
      Reviewers: simonpj, bgamari, austin, goldfire
      
      Subscribers: thomie, rwbarton
      
      GHC Trac Issues: #14396
      
      Differential Revision: https://phabricator.haskell.org/D4154
      69987720
  24. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  25. 15 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14060 by more conservatively annotating TH-reified types · ad7b9452
      Ryan Scott authored
      Before, TH was quite generous in applying kind annotations to reified
      type constructors whose result kind happened to mention type variables.
      This could result in agonizingly large reified types, so this patch aims
      to quell this a bit by adopting a more nuanced algorithm for determining
      when a tycon application deserves a kind annotation.
      
      This implements the algorithm laid out in
      https://ghc.haskell.org/trac/ghc/ticket/14060#comment:1. I've updated
      `Note [Kind annotations on TyConApps]` to reflect the new wisdom.
      Essentially, instead of only checking if the result kind contains free
      variables, we also check if any of those variables do not appear free in
      injective positions in the argument kinds—only then do we put on a kind
      annotation.
      
      Bumps `haddock` submodule.
      
      Test Plan: make test TEST=T14060
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14060
      
      Differential Revision: https://phabricator.haskell.org/D3807
      ad7b9452
  26. 20 Jul, 2017 1 commit
  27. 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
      a786b136
  28. 31 May, 2017 1 commit
  29. 14 Feb, 2017 1 commit
    • rwbarton's avatar
      Check local type family instances against all imported ones · bedcb716
      rwbarton authored
      We previously checked type family instance declarations
      in a module for consistency with all instances that we happened
      to have read into the EPS or HPT. It was possible to arrange that
      an imported type family instance (used by an imported function)
      was in a module whose interface file was never read during
      compilation; then we wouldn't check consistency of local instances
      with this imported instance and as a result type safety was lost.
      
      With this patch, we still check consistency of local type family
      instances with all type family instances that we have loaded; but
      we make sure to load the interface files of all our imports that
      define family instances first. More selective consistency checking
      is left to #13102.
      
      On the other hand, we can now safely assume when we import a module
      that it has been checked for consistency with its imports. So we
      can save checking in checkFamInstConsistency, and overall we should
      have less work to do now.
      
      This patch also adds a note describing the Plan for ensuring type
      family consistency.
      
      Test Plan: Two new tests added; harbormaster
      
      Reviewers: austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: ggreif, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2992
      bedcb716
  30. 06 Feb, 2017 1 commit
    • rwbarton's avatar
      Don't replace type family instances with the same LHS in GHCi (#7102) · 0abe7361
      rwbarton authored
      This fixes the easy part of #7102 by removing the logic that lets the
      user replace a type family instance with a new one with the same LHS.
      As discussed on that ticket, this is unsound in general. Better to have
      the user redefine the type family from scratch.
      
      The example from comment:7 involving loading modules into ghci is not
      fixed yet; it actually doesn't rely on the instances having the same LHS.
      This commit adds an expect_broken test for that example as well.
      
      Test Plan: T7102a for the fix; T7102 is the test not fixed yet
      
      Reviewers: dfeuer, austin, bgamari, goldfire
      
      Reviewed By: dfeuer
      
      Subscribers: dfeuer, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2994
      0abe7361
  31. 23 Jan, 2017 1 commit
    • niteria's avatar
      Make checkFamInstConsistency faster · 18ceb148
      niteria authored
      We've noticed that `checkFamInstConsistency` takes 6% of
      overall build time on our codebase.
      I've poked around for a bit and most of type family
      instances are `Rep` from `Generics`. I think those are
      unavoidable, so I don't think we can have less of them.
      
      I also looked at the code and noticed a simple algorithmic
      improvement can be made. The algorithm is pretty simple:
      we take all the family instances from one module (`M1`)
      and test it against another module (`M2`).
      The cost of that is dominated by the size of `M1`, because
      for each instance in `M1` we look it up in the type family
      env from `M2`, and lookup is cheap.
      If `M1` is bigger than `M2`, that's suboptimal, so after
      my change we always iterate through the smaller set.
      
      This drives down the cost of `checkFamInstConsistency`
      to 2%.
      
      Test Plan: harbormaster
      
      Reviewers: simonmar, simonpj, goldfire, rwbarton, bgamari, ezyang, austin
      
      Reviewed By: rwbarton, ezyang
      
      Subscribers: ezyang, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2833
      18ceb148
  32. 18 Dec, 2016 2 commits
  33. 04 Nov, 2016 1 commit
  34. 18 Oct, 2016 1 commit
  35. 28 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Deal correctly with unused imports for 'coerce' · 23b80ac4
      Simon Peyton Jones authored
      We only do newtype unwrapping for Coercible constraints if
      the newtype's data constructor is in scope.  We were trying to
      record the fact that the data constructor was thereby 'used', so
      that an import statement would not be flagged as unnecsssary
      (by -Wunused-imports).
      
      But the code was simply wrong. It was wrong because it assumed
      that only one level of unwrapping happened, whereas
      tcTopNormaliseNewTypeTF_maybe actually unwraps multiple layers.
      So we need to return a /list/ of data constructors that are used.
      
      This entailed a bit of refactoring, as usual.
      
      Fixes Trac #12067
      23b80ac4
  36. 23 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Give lookupGRE_Name a better API · 3e0af469
      Simon Peyton Jones authored
      lookupGRE_Name should return either zero or one GREs, never
      several. This is a consequence of INVARIANT 1 on GlobalRdrEnv.
      
      So it's better if it returns a Maybe; the panic on multiple results
      is put in one place, instead of being scattered or ignored.
      
      Just refactoring, no change in behaviour
      3e0af469
  37. 22 Jun, 2016 1 commit
    • niteria's avatar
      Make the Ord Module independent of Unique order (2nd try) · 348f2dbb
      niteria authored
      The `Ord Module` instance currently uses `Unique`s for comparison.
      We don't want to use the `Unique` order because it can introduce
      nondeterminism.
      This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic
      ordering making `Ord Module` deterministic transitively.
      
      I've run `nofib` and it doesn't make a measurable difference.
      
      See also Note [ModuleEnv determinism and performance].
      
      This fixes #12191 - the regression, that the previous version of this
      patch had.
      
      Test Plan:
      ./validate
      run nofib: P112
      
      Reviewers: simonmar, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2354
      
      GHC Trac Issues: #4012, #12191
      348f2dbb