1. 15 Aug, 2019 1 commit
    • James Foster's avatar
      Remove unused imports of the form 'import foo ()' (Fixes #17065) · ca71d551
      James Foster authored
      These kinds of imports are necessary in some cases such as
      importing instances of typeclasses or intentionally creating
      dependencies in the build system, but '-Wunused-imports' can't
      detect when they are no longer needed. This commit removes the
      unused ones currently in the code base (not including test files
      or submodules), with the hope that doing so may increase
      parallelism in the build system by removing unnecessary
      dependencies.
      ca71d551
  2. 10 Aug, 2019 1 commit
    • Ben Gamari's avatar
      Add timing on loadInterface · 422ffce0
      Ben Gamari authored
      AndreasK recently mentioned that he thought that interface file loading
      may be a non-trivial cost. Let's measure.
      422ffce0
  3. 07 Aug, 2019 2 commits
    • mniip's avatar
    • mniip's avatar
      Add a -fprint-axiom-incomps option (#15546) · 2073745c
      mniip authored
      Supply branch incomps when building an IfaceClosedSynFamilyTyCon
      
      `pprTyThing` now has access to incomps. This also causes them to be
      written out to .hi files, but that doesn't pose an issue other than a
      more faithful bijection between `tyThingToIfaceDecl` and `tcIfaceDecl`.
      
      The machinery for displaying axiom incomps was already present but not
      in use. Since this is now a thing that pops up in ghci's :info the
      format was modified to look like a haskell comment.
      
      Documentation and a test for the new feature included.
      
      Test Plan: T15546
      
      Reviewers: simonpj, bgamari, goldfire
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15546
      
      Differential Revision: https://phabricator.haskell.org/D5097
      2073745c
  4. 31 Jul, 2019 2 commits
    • Ben Gamari's avatar
      Work around redundant import issue · 787fab43
      Ben Gamari authored
      As mentioned in #16997, GHC currently complains about this import.
      In general I'm reluctant to paper over things like this but in the case
      of an hs-boot file I think adding an import list is the right thing to
      do regardless of the bug.
      787fab43
    • Ben Gamari's avatar
      Break up TyCoRep · 371dadfb
      Ben Gamari authored
      This breaks up the monstrous TyCoReps module into several new modules by
      topic:
      
       * TyCoRep: Contains the `Coercion`, `Type`, and related type
         definitions and a few simple predicates but nothing further
      
       * TyCoPpr: Contains the the pretty-printer logic
      
       * TyCoFVs: Contains the free variable computations (and
         `tyConAppNeedsKindSig`, although I suspect this should change)
      
       * TyCoSubst: Contains the substitution logic for types and coercions
      
       * TyCoTidy: Contains the tidying logic for types
      
      While we are able to eliminate a good number of `SOURCE` imports (and
      make a few others smaller) with this change, we must introduce one new
      `hs-boot` file for `TyCoPpr` so that `TyCoRep` can define `Outputable`
      instances for the types it defines.
      
      Metric Increase:
          haddock.Cabal
          haddock.compiler
      371dadfb
  5. 10 Jul, 2019 1 commit
  6. 20 Jun, 2019 1 commit
    • John Ericson's avatar
      Move 'Platform' to ghc-boot · bff2f24b
      John Ericson authored
      ghc-pkg needs to be aware of platforms so it can figure out which
      subdire within the user package db to use. This is admittedly
      roundabout, but maybe Cabal could use the same notion of a platform as
      GHC to good affect too.
      bff2f24b
  7. 24 May, 2019 1 commit
    • Michael Sloan's avatar
      Add PlainPanic for throwing exceptions without depending on pprint · d9dfbde3
      Michael Sloan authored
      This commit splits out a subset of GhcException which do not depend on
      pretty printing (SDoc), as a new datatype called
      PlainGhcException. These exceptions can be caught as GhcException,
      because 'fromException' will convert them.
      
      The motivation for this change is that that the Panic module
      transitively depends on many modules, primarily due to pretty printing
      code.  It's on the order of about 130 modules.  This large set of
      dependencies has a few implications:
      
      1. To avoid cycles / use of boot files, these dependencies cannot
      throw GhcException.
      
      2. There are some utility modules that use UnboxedTuples and also use
      `panic`. This means that when loading GHC into GHCi, about 130
      additional modules would need to be compiled instead of
      interpreted. Splitting the non-pprint exception throwing into a new
      module resolves this issue. See #13101
      d9dfbde3
  8. 03 May, 2019 2 commits
    • Ryan Scott's avatar
      Make equality constraints in kinds invisible · cc495d57
      Ryan Scott authored
      Issues #12102 and #15872 revealed something strange about the way GHC
      handles equality constraints in kinds: it treats them as _visible_
      arguments! This causes a litany of strange effects, from strange
      error messages
      (ghc/ghc#12102 (comment 169035))
      to bizarre `Eq#`-related things leaking through to GHCi output, even
      without any special flags enabled.
      
      This patch is an attempt to contain some of this strangeness.
      In particular:
      
      * In `TcHsType.etaExpandAlgTyCon`, we propagate through the
        `AnonArgFlag`s of any `Anon` binders. Previously, we were always
        hard-coding them to `VisArg`, which meant that invisible binders
        (like those whose kinds were equality constraint) would mistakenly
        get flagged as visible.
      * In `ToIface.toIfaceAppArgsX`, we previously assumed that the
        argument to a `FunTy` always corresponding to a `Required`
        argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map
        `VisArg` to `Required` and `InvisArg` to `Inferred`. As a
        consequence, the iface pretty-printer correctly recognizes that
        equality coercions are inferred arguments, and as a result,
        only displays them in `-fprint-explicit-kinds` is enabled.
      * Speaking of iface pretty-printing, `Anon InvisArg` binders were
        previously being pretty-printed like `T (a :: b ~ c)`, as if they
        were required. This seemed inconsistent with other invisible
        arguments (that are printed like `T @{d}`), so I decided to switch
        this to `T @{a :: b ~ c}`.
      
      Along the way, I also cleaned up a minor inaccuracy in the users'
      guide section for constraints in kinds that was spotted in
      ghc/ghc#12102 (comment 136220).
      
      Fixes #12102 and #15872.
      cc495d57
    • Ömer Sinan Ağacan's avatar
      Fix interface version number printing in --show-iface · 87bc954a
      Ömer Sinan Ağacan authored
      Before
      
          Version: Wanted [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5],
                   got    [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5]
      
      After
      
          Version: Wanted 809020190425,
                   got    809020190425
      87bc954a
  9. 04 Apr, 2019 1 commit
  10. 25 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      Update Wiki URLs to point to GitLab · 3769e3a8
      Takenobu Tani authored
      This moves all URL references to Trac Wiki to their corresponding
      GitLab counterparts.
      
      This substitution is classified as follows:
      
      1. Automated substitution using sed with Ben's mapping rule [1]
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...
      
      2. Manual substitution for URLs containing `#` index
          Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
          New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz
      
      3. Manual substitution for strings starting with `Commentary`
          Old: Commentary/XxxYyy...
          New: commentary/xxx-yyy...
      
      See also !539
      
      [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
      3769e3a8
  11. 15 Mar, 2019 1 commit
  12. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
      by adding the ability to write kinds with
      visible dependent quantification (VDQ).
      
      Most of the work for supporting VDQ was actually done _before_ this
      patch. That is, GHC has been able to reason about kinds with VDQ for
      some time, but it lacked the ability to let programmers directly
      write these kinds in the source syntax. This patch is primarly about
      exposing this ability, by:
      
      * Changing `HsForAllTy` to add an additional field of type
        `ForallVisFlag` to distinguish between invisible `forall`s (i.e,
        with dots) and visible `forall`s (i.e., with arrows)
      * Changing `Parser.y` accordingly
      
      The rest of the patch mostly concerns adding validity checking to
      ensure that VDQ is never used in the type of a term (as permitting
      this would require full-spectrum dependent types). This is
      accomplished by:
      
      * Adding a `vdqAllowed` predicate to `TcValidity`.
      * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
        that only splits invisible `forall`s. This function is used in
        certain places (e.g., in instance declarations) to ensure that GHC
        doesn't try to split visible `forall`s (e.g., if it tried splitting
        `instance forall a -> Show (Blah a)`, then GHC would mistakenly
        allow that declaration!)
      
      This also updates Template Haskell by introducing a new `ForallVisT`
      constructor to `Type`.
      
      Fixes #16326. Also fixes #15658 by documenting this feature in the
      users' guide.
      c26d299d
  13. 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
        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
  14. 12 Feb, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16299 by deleting incorrect code from IfaceSyn · 8b476d82
      Ryan Scott authored
      GHCi's `:info` command was pretty-printing Haskell98-style data types
      with explicit return kinds if the return kind wasn't `Type`. This
      leads to bizarre output like this:
      
      ```
      λ> :i (##)
      data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##)
              -- Defined in ‘GHC.Prim’
      ```
      
      Or, with unlifted newtypes:
      
      ```
      λ> newtype T = MkT Int#
      λ> :i T
      newtype T :: TYPE 'IntRep = MkT Int#
              -- Defined at <interactive>:5:1
      ```
      
      The solution is simple: just delete one part from `IfaceSyn` where
      GHC mistakenly pretty-prints the return kinds for non-GADTs.
      8b476d82
  15. 22 Dec, 2018 1 commit
  16. 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
  17. 20 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Refine the suppression of RuntimeRep variables · 5f2a8793
      Simon Peyton Jones authored
      When we pretty-print types, we suppress RuntimeRep variables, but
      we were being too aggressive in doing so, resulting in Trac #16074.
      
      This patch makes the suppression a bit less aggressive.
      See Note [Defaulting RuntimeRep variables]
      5f2a8793
  18. 19 Dec, 2018 1 commit
    • Ryan Scott's avatar
      Fix #16030 by refactoring IfaceSyn's treatment of GADT constructors · 9d9e3557
      Ryan Scott authored
      Summary:
      GHCi's `:info` command was pretty-printined GADT
      constructors suboptimally in the following ways:
      
      1. Sometimes, fields were parenthesized when they did not need it,
         e.g.,
      
      ```lang=haskell
      data Foo a where
        MkFoo :: (Maybe a) -> Foo a
      ```
      
         I fixed this by refactoring some code in `pprIfaceConDecl` to be a
         little smarter with respect to GADT syntax. See `pprFieldArgTy`
         and `pprArgTy`.
      2. With `-fprint-explicit-kinds` enabled, there would be times when
         specified arguments would be printed without a leading `@` in GADT
         return types, e.g.,
      
      ```lang=haskell
      data Bar @k (a :: k) where
        MkBar :: Bar k a
      ```
      
         It turns out that `ppr_tc_app`, the function which pretty-prints
         these return types, was not using the proper machinery to print
         out the arguments, which caused the visibilities to be forgotten
         entirely. I refactored `ppr_tc_app` to do this correctly.
      
      Test Plan: make test TEST=T16030
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #16030
      
      Differential Revision: https://phabricator.haskell.org/D5440
      9d9e3557
  19. 13 Dec, 2018 1 commit
    • Daniel Gröber (dxld)'s avatar
      Fix recompilation checking of pure plugins · efb6a30f
      Daniel Gröber (dxld) authored
      Previously when switching from using a Plugin with
      `RecompMaybe`/`ForceRecompile` in `pluginRecompile` to a Plugin with
      `NoForceRecompile` GHC would never even consider recompiling.
      
      However the previously active plugin could have modified the
      compilation output so we should recompile.
      
      Test Plan: validate
      
      Reviewers: bgamari, mpickering
      
      Subscribers: mpickering, rwbarton, carter
      
      GHC Trac Issues: #15858
      
      Differential Revision: https://phabricator.haskell.org/D5299
      efb6a30f
  20. 11 Dec, 2018 3 commits
    • Alec Theriault's avatar
      Support generating HIE files · f582379d
      Alec Theriault authored
      Adds a `-fenable-ide-info` flag which instructs GHC to generate `.hie`
      files (see the wiki page:
      https://ghc.haskell.org/trac/ghc/wiki/HIEFiles).
      
      This is a rebased version of Zubin Duggal's (@wz1000) GHC changes for
      his GSOC project, as posted here:
      https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, gershomb, nomeata, alanz, sjakobi
      
      Reviewed By: alanz, sjakobi
      
      Subscribers: alanz, hvr, sjakobi, rwbarton, wz1000, carter
      
      Differential Revision: https://phabricator.haskell.org/D5239
      f582379d
    • Daniel Gröber (dxld)'s avatar
      Support registering Plugins through the GHC API · da05d79d
      Daniel Gröber (dxld) authored
      This allows tooling using the GHC API to use plugins internally.
      Hopefully this will make it possible to decouple the development of
      useful plugins from (currently) kitchen-sink type tooling projects
      such as ghc-mod or HIE -- at least to some extent.
      
      Test Plan: validate
      
      Reviewers: bgamari, mpickering
      
      Subscribers: mpickering, alanz, rwbarton, carter
      
      GHC Trac Issues: #15826
      
      Differential Revision: https://phabricator.haskell.org/D5278
      da05d79d
    • Simon Marlow's avatar
      Fix recompilation bug with default class methods (#15970) · 288f681e
      Simon Marlow authored
      If a module uses a class, then it can instantiate the class and
      thereby use its default methods, so we must include the default
      methods when calculating the fingerprint for the class.
      
      Test Plan:
      New unit test: driver/T15970
      
      Before:
      
      ```
      =====> T15970(normal) 1 of 1 [0, 0, 0]
      cd "T15970.run" && $MAKE -s --no-print-directory T15970
      Wrong exit code for T15970()(expected 0 , actual 2 )
      Stdout ( T15970 ):
      Makefile:13: recipe for target 'T15970' failed
      Stderr ( T15970 ):
      C.o:function Main_zdfTypeClassMyDataType1_info: error: undefined
      reference to 'A_toTypedData2_closure'
      C.o:function Main_main1_info: error: undefined reference to
      'A_toTypedData2_closure'
      C.o(.data+0x298): error: undefined reference to 'A_toTypedData2_closure'
      C.o(.data+0x480): error: undefined reference to 'A_toTypedData2_closure'
      collect2: error: ld returned 1 exit status
      `gcc' failed in phase `Linker'. (Exit code: 1)
      ```
      
      After: test passes.
      
      Reviewers: bgamari, simonpj, erikd, watashi, afarmer
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15970
      
      Differential Revision: https://phabricator.haskell.org/D5394
      288f681e
  21. 03 Dec, 2018 1 commit
  22. 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
  23. 26 Nov, 2018 2 commits
    • Ryan Scott's avatar
      Fix #15941 by only special-casing visible infix applications · 984b75de
      Ryan Scott authored
      Summary:
      The iface pretty-printer had a special case for an
      application of an infix type constructor to two arguments. But this
      didn't take the visibilities of the arguments into account, which
      could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when
      `-fprint-explicit-kinds` was enabled (#15941). The fix is relatively
      straightforward: simply plumb through the visibilities of each
      argument, and only trigger the special case for infix applications
      if both arguments are visible (i.e., required).
      
      Test Plan: make test TEST=T15941
      
      Reviewers: goldfire, bgamari, monoidal
      
      Reviewed By: goldfire, monoidal
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15941
      
      Differential Revision: https://phabricator.haskell.org/D5375
      984b75de
    • Ryan Scott's avatar
      Print explicit foralls in type family eqns when appropriate · f932b1aa
      Ryan Scott authored
      Summary:
      When `-fprint-explicit-foralls` is enabled, type family
      equations are either printed without an explict `forall` entirely,
      or with a bizarre square bracket syntax (in the case of closed type
      families). I find neither satisfying, so in this patch, I introduce
      support for printing explicit `forall`s in open type-family, closed
      type-family, and data-family equations when appropriate. (By "when
      appropriate", I refer to the conditions laid out in
      `Note [When to print foralls]` in `IfaceType`.)
      
      One tricky point in the implementation is that I had to pick a
      visibility for each type variable in a `CoAxiom`/`FamInst` in order
      to be able to pass it to `pprUserIfaceForAll` //et al.// Because
      the type variables in a type family instance equation can't be
      instantiated by the programmer anyway, the choice only really matters
      for pretty-printing purposes, so I simply went with good ol'
      trustworthy `Specified`. (This design choice is documented in
      `Note [Printing foralls in type family instances]` in `IfaceType`.)
      
      Test Plan: make test TEST=T15827
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15827
      
      Differential Revision: https://phabricator.haskell.org/D5282
      f932b1aa
  24. 22 Nov, 2018 2 commits
    • 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
    • Ryan Scott's avatar
      Fix #15852 by eta expanding data family instance RHSes, too · 014d6c1f
      Ryan Scott authored
      When I defined `etaExpandFamInstLHS`, I blatantly forgot
      to eta expand the RHSes of data family instances. (Actually, I
      claimed that they didn't //need// to be eta expanded. I'm not sure
      what I was thinking.)
      
      This fixes the issue by changing `etaExpandFamInstLHS` to
      `etaExpandFamInst` and, well, making it actually eta expand the RHS.
      
      Test Plan: make test TEST=T15852
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15852
      
      Differential Revision: https://phabricator.haskell.org/D5328
      014d6c1f
  25. 15 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Smarter HsType pretty-print for promoted datacons · ae2c9b40
      Simon Peyton Jones authored
      Fix Trac #15898, by being smarter about when to print
      a space before a promoted data constructor, in a HsType.
      I had to implement a mildly tiresome function
          HsType.lhsTypeHasLeadingPromotionQuote
      It has multiple cases, of course, but it's very simple.
      
      The patch improves the error-message output in a bunch of
      cases, and (to my surprise) actually fixes a bug in the
      output of T14343 (Trac #14343), thus
      
        -  In the expression: _ :: Proxy '('( 'True,  'False),  'False)
        +  In the expression: _ :: Proxy '( '( 'True, 'False), 'False)
      
      I discovered that there were two copies of the PromotionFlag
      type (a boolean, with helpfully named data cons), one in
      IfaceType and one in HsType.  So I combined into one,
      PromotionFlag, and moved it to BasicTypes.  That's why
      quite a few files are touched, but it's all routine.
      ae2c9b40
  26. 01 Nov, 2018 1 commit
    • Richard Eisenberg's avatar
      Fix embarrassing, egregious bug in roles of (->) · 255d2e32
      Richard Eisenberg authored
      Previously, I had inexplicably decided that (->)'s roles
      were all Representational. But, of course, its first two
      parameters are *dependent* RuntimeReps. All dependent parameters
      have a Nominal role, because all roles in kinds are Nominal.
      
      Fix is easy, but I have no idea how the world hasn't come
      crashing down before now.
      
      This was found while investigating #15801, which requires
      visible type application in types to observe. Hence, the test
      case will come with the main patch for #12045.
      255d2e32
  27. 04 Oct, 2018 2 commits
    • Alec Theriault's avatar
      Improve generated `GHC.Prim` docs · feb8a671
      Alec Theriault authored
      Summary:
      * Extended `genprimcode` to generate Haddock-compatible deprecations,
        as well as displaying information about which functions are LLVM-only
        and which functions can fail with an unchecked exception.
      
      * Ported existing deprecations to the new format, and also added a
        deprecation on `par#` (see Trac #15227).
      
      * Emit an error on fixity/deprecation of builtins, unless we are
        processing the module in which that name is defined (see Trac #15233).
        That means the following is no longer accepted (outside of `GHC.Types`):
      
      ```
      infixr 7 :
      {-# DEPRECATED (:) "cons is deprecated" #-}
      ```
      
      * Generate `data (->) a b` with docs and fixity in `GHC.Prim`. This
        means: GHC can now parse `data (->) a b` and `infixr 0 ->` (only in
        `GHC.Prim`) and `genprimcode` can digest `primtype (->) a b` (See Trac
        #4861)
      
      as well as some misc fixes along the way.
      
      Reviewers: bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, mpickering, carter
      
      GHC Trac Issues: #15227, #15233, #4861
      
      Differential Revision: https://phabricator.haskell.org/D5167
      feb8a671
    • Simon Peyton Jones's avatar
      Better pretty-printing of forall types · 37ef7031
      Simon Peyton Jones authored
      Currently forall-types with a lot of type variables,
      or type variables with big kinds, are pretty-printed too
      horizontally, and dribble off to the right in an illegible
      way.
      
      This patch treats the type variables as a group, and uses
      'fsep' to lay them out decently.
      37ef7031
  28. 03 Oct, 2018 1 commit
    • Ryan Scott's avatar
      Drop GHC 8.2 compatibility · a838ae37
      Ryan Scott authored
      Summary:
      GHC 8.6.1 is out, so now GHC's support window only extends
      back to GHC 8.4. This means we can delete gobs of code that were
      only used for GHC 8.2 support. Hooray!
      
      Test Plan: ./validate
      
      Reviewers: bgamari, Phyx, erikd
      
      Reviewed By: bgamari, Phyx
      
      Subscribers: rwbarton, erikd, carter
      
      Differential Revision: https://phabricator.haskell.org/D5192
      a838ae37
  29. 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.
      
      Acknowledgments:
      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
      ea5ade34
  30. 13 Sep, 2018 1 commit
  31. 30 Aug, 2018 1 commit
  32. 24 Aug, 2018 1 commit