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. 12 Feb, 2020 1 commit
  3. 08 Jan, 2020 1 commit
    • Ryan Scott's avatar
      Print Core type applications with no whitespace after @ (#17643) · 923a1272
      Ryan Scott authored
      This brings the pretty-printer for Core in line with how visible
      type applications are normally printed: namely, with no whitespace
      after the `@` character (i.e., `f @a` instead of `f @ a`). While I'm
      in town, I also give the same treatment to type abstractions (i.e.,
      `\(@a)` instead of `\(@ a)`) and coercion applications (i.e.,
      `f @~x` instead of `f @~ x`).
      Fixes #17643.
  4. 06 Jan, 2020 1 commit
  5. 04 Jan, 2020 1 commit
  6. 05 Dec, 2019 1 commit
    • Vladislav Zavialov's avatar
      Pretty-printing of the * kind · 3354c68e
      Vladislav Zavialov authored
      Before this patch, GHC always printed the * kind unparenthesized.
      This led to two issues:
      1. Sometimes GHC printed invalid or incorrect code.
         For example, GHC would print:  type F @*   x = x
               when it meant to print:  type F @(*) x = x
         In the former case, instead of a kind application we were getting a
         type operator (@*).
      2. Sometimes GHC printed kinds that were correct but hard to read.
         Should  Either * Int  be read as  Either (*) Int
                                    or as  (*) Either Int  ?
         This depends on whether -XStarIsType is enabled, but it would be
         easier if we didn't have to check for the flag when reading the code.
      We can solve both problems by assigning (*) a different precedence. Note
      that Haskell98 kinds are not affected:
        ((* -> *) -> *) -> *  does NOT become  (((*) -> (*)) -> (*)) -> (*)
      The parentheses are added when (*) is used in a function argument
         F * * *   becomes  F (*) (*) (*)
         F A * B   becomes  F A (*) B
         Proxy *   becomes  Proxy (*)
         a * -> *  becomes  a (*) -> *
  7. 28 Nov, 2019 1 commit
  8. 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:
  9. 07 Nov, 2019 1 commit
    • Ryan Scott's avatar
      Clean up TH's treatment of unary tuples (or, #16881 part two) · 708c60aa
      Ryan Scott authored
      !1906 left some loose ends in regards to Template Haskell's treatment
      of unary tuples. This patch ends to tie up those loose ends:
      * In addition to having `TupleT 1` produce unary tuples, `TupE [exp]`
        and `TupP [pat]` also now produce unary tuples.
      * I have added various special cases in GHC's pretty-printers to
        ensure that explicit 1-tuples are printed using the `Unit` type.
        See `testsuite/tests/th/T17380`.
      * The GHC 8.10.1 release notes entry has been tidied up a little.
      Fixes #16881. Fixes #17371. Fixes #17380.
  10. 27 Oct, 2019 1 commit
    • Ryan Scott's avatar
      Parenthesize nullary constraint tuples using sigPrec (#17403) · fa0d4809
      Ryan Scott authored
      We were using `appPrec`, not `sigPrec`, as the precedence when
      determining whether or not to parenthesize `() :: Constraint`,
      which lead to the parentheses being omitted in function contexts
      like `(() :: Constraint) => String`. Easily fixed.
      Fixes #17403.
  11. 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
      (Original code written by @AndreasK in !1530)
      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
      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>
  12. 25 Sep, 2019 1 commit
    • Vladislav Zavialov's avatar
      Standalone kind signatures (#16794) · 0b5eede9
      Vladislav Zavialov authored
      Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst
      With this patch, a type constructor can now be given an explicit
      standalone kind signature:
        {-# LANGUAGE StandaloneKindSignatures #-}
        type Functor :: (Type -> Type) -> Constraint
        class Functor f where
          fmap :: (a -> b) -> f a -> f b
      This is a replacement for CUSKs (complete user-specified
      kind signatures), which are now scheduled for deprecation.
      User-facing changes
      * A new extension flag has been added, -XStandaloneKindSignatures, which
        implies -XNoCUSKs.
      * There is a new syntactic construct, a standalone kind signature:
          type <name> :: <kind>
        Declarations of data types, classes, data families, type families, and
        type synonyms may be accompanied by a standalone kind signature.
      * A standalone kind signature enables polymorphic recursion in types,
        just like a function type signature enables polymorphic recursion in
        terms. This obviates the need for CUSKs.
      * TemplateHaskell AST has been extended with 'KiSigD' to represent
        standalone kind signatures.
      * GHCi :info command now prints the kind signature of type constructors:
          ghci> :info Functor
          type Functor :: (Type -> Type) -> Constraint
      * 'forall'-bound type variables of a standalone kind signature do not
        scope over the declaration body, even if the -XScopedTypeVariables is
        enabled. See #16635 and #16734.
      * Wildcards are not allowed in standalone kind signatures, as partial
        signatures do not allow for polymorphic recursion.
      * Associated types may not be given an explicit standalone kind
        signature. Instead, they are assumed to have a CUSK if the parent class
        has a standalone kind signature and regardless of the -XCUSKs flag.
      * Standalone kind signatures do not support multiple names at the moment:
          type T1, T2 :: Type -> Type   -- rejected
          type T1 = Maybe
          type T2 = Either String
        See #16754.
      * Creative use of equality constraints in standalone kind signatures may
        lead to GHC panics:
          type C :: forall (a :: Type) -> a ~ Int => Constraint
          class C a where
            f :: C a => a -> Int
        See #16758.
      Implementation notes
      * The heart of this patch is the 'kcDeclHeader' function, which is used to
        kind-check a declaration header against its standalone kind signature.
        It does so in two rounds:
          1. check user-written binders
          2. instantiate invisible binders a la 'checkExpectedKind'
      * 'kcTyClGroup' now partitions declarations into declarations with a
        standalone kind signature or a CUSK (kinded_decls) and declarations
        without either (kindless_decls):
          * 'kinded_decls' are kind-checked with 'checkInitialKinds'
          * 'kindless_decls' are kind-checked with 'getInitialKinds'
      * DerivInfo has been extended with a new field:
          di_scoped_tvs :: ![(Name,TyVar)]
        These variables must be added to the context in case the deriving clause
        references tcTyConScopedTyVars. See #16731.
  13. 31 Jul, 2019 1 commit
    • Ben Gamari's avatar
      Break up TyCoRep · 371dadfb
      Ben Gamari authored
      This breaks up the monstrous TyCoReps module into several new modules by
       * 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:
  14. 03 May, 2019 1 commit
    • 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.
  15. 15 Mar, 2019 1 commit
  16. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      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.
  17. 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
  18. 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]
  19. 19 Dec, 2018 1 commit
    • Ryan Scott's avatar
      Fix #16030 by refactoring IfaceSyn's treatment of GADT constructors · 9d9e3557
      Ryan Scott authored
      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,
      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.,
      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
  20. 03 Dec, 2018 1 commit
  21. 26 Nov, 2018 2 commits
    • Ryan Scott's avatar
      Fix #15941 by only special-casing visible infix applications · 984b75de
      Ryan Scott authored
      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
    • Ryan Scott's avatar
      Print explicit foralls in type family eqns when appropriate · f932b1aa
      Ryan Scott authored
      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
  22. 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
  23. 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
      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.
  24. 04 Oct, 2018 1 commit
    • 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
      This patch treats the type variables as a group, and uses
      'fsep' to lay them out decently.
  25. 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
  26. 24 Aug, 2018 1 commit
  27. 05 Aug, 2018 1 commit
  28. 11 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Use IfaceAppArgs to store an IfaceAppTy's arguments · 1c353623
      Ryan Scott authored
      Currently, an `IfaceAppTy` has no way to tell whether its
      argument is visible or not, so it simply treats all arguments as
      visible, leading to #15330. We already have a solution for this
      problem in the form of the `IfaceTcArgs` data structure, used by
      `IfaceTyConApp` to represent the arguments to a type constructor.
      Therefore, it makes sense to reuse this machinery for `IfaceAppTy`,
      so this patch does just that.
      This patch:
      1. Renames `IfaceTcArgs` to `IfaceAppArgs` to reflect its more
         general purpose.
      2. Changes the second field of `IfaceAppTy` from `IfaceType` to
         `IfaceAppArgs`, and propagates the necessary changes through. In
         particular, pretty-printing an `IfaceAppTy` now goes through the
         `IfaceAppArgs` pretty-printer, which correctly displays arguments
         as visible or not for free, fixing #15330.
      3. Changes `toIfaceTypeX` and related functions so that when
         converting an `AppTy` to an `IfaceAppTy`, it flattens as many
         argument `AppTy`s as possible, and then converts those arguments
         into an `IfaceAppArgs` list, using the kind of the function
         `Type` as a guide. (Doing so minimizes the number of times we need
         to call `typeKind`, which is more expensive that finding the kind
         of a `TyCon`.)
      Test Plan: make test TEST=T15330
      Reviewers: goldfire, simonpj, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15330
      Differential Revision: https://phabricator.haskell.org/D4938
  29. 10 Jul, 2018 1 commit
    • Ningning Xie's avatar
      Refactor coercion rule · 55a3f855
      Ningning Xie authored
      The patch is an attempt on #15192.
      It defines a new coercion rule
       | GRefl Role Type MCoercion
      which correspondes to the typing rule
           t1 : k1
        GRefl r t1 MRefl: t1 ~r t1
           t1 : k1       co :: k1 ~ k2
        GRefl r t1 (MCo co) : t1 ~r t1 |> co
      MCoercion wraps a coercion, which might be reflexive (MRefl)
      or not (MCo co). To know more about MCoercion see #14975.
      We keep Refl ty as a special case for nominal reflexive coercions,
      naemly, Refl ty :: ty ~n ty.
      This commit is meant to be a general performance improvement,
      but there are a few regressions. See #15192, comment:13 for
      more information.
      Test Plan: ./validate
      Reviewers: bgamari, goldfire, simonpj
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15192
      Differential Revision: https://phabricator.haskell.org/D4747
  30. 05 Jul, 2018 2 commits
    • Ryan Scott's avatar
      Make ppr_tc_args aware of -fprint-explicit-kinds · dbdcacfc
      Ryan Scott authored
      `ppr_tc_args` was printing invisible kind arguments even
      when `-fprint-explicit-kinds` wasn't enabled. Easily fixed.
      Test Plan: make test TEST=T15341
      Reviewers: goldfire, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rwbarton, thomie, carter
      GHC Trac Issues: #15341
      Differential Revision: https://phabricator.haskell.org/D4932
    • Ryan Scott's avatar
      Fix #15308 by suppressing invisble args more rigorously · 93b7ac8d
      Ryan Scott authored
      There was a buglet in `stripInvisArgs` (which is part of the
      pretty-printing pipeline for types) in which only invisble arguments
      which came before any visible arguments would be suppressed, but any
      invisble arguments that came //after// visible ones would still be
      printed, even if `-fprint-explicit-kinds`  wasn't enabled.
      The fix is simple: make `stripInvisArgs` recursively process the
      remaining types even after a visible argument is encountered.
      Test Plan: make test TEST=T15308
      Reviewers: goldfire, bgamari
      Reviewed By: bgamari
      Subscribers: simonpj, rwbarton, thomie, carter
      GHC Trac Issues: #15308
      Differential Revision: https://phabricator.haskell.org/D4891
  31. 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
  32. 08 Jun, 2018 1 commit
  33. 07 Jun, 2018 1 commit
    • Andreas Herrmann's avatar
      Fix unparseable pretty-printing of promoted data cons · 767536cc
      Andreas Herrmann authored
      Previously we would print code which would not round-trip:
      > :set -XDataKinds
      > :set -XPolyKinds
      > data Proxy k = Proxy
      > _ :: Proxy '[ 'True ]
        Found hole: _ :: Proxy '['True]
      > _ :: Proxy '['True]
          Invalid type signature: _ :: ...
          Should be of form <variable> :: <type>
      Test Plan: Validate with T14343
      Reviewers: RyanGlScott, goldfire, bgamari, tdammers
      Reviewed By: RyanGlScott, bgamari
      Subscribers: tdammers, rwbarton, thomie, carter
      GHC Trac Issues: #14343
      Differential Revision: https://phabricator.haskell.org/D4746
  34. 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
  35. 16 May, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15039 by pretty-printing equalities more systematically · 99f8cc84
      Ryan Scott authored
      GHC previously had a handful of special cases for
      pretty-printing equalities in a more user-friendly manner, but they
      were far from comprehensive (see #15039 for an example of where this
      fell apart).
      This patch makes the pretty-printing of equalities much more
      systematic. I've adopted the approach laid out in
      https://ghc.haskell.org/trac/ghc/ticket/15039#comment:4, and updated
      `Note [Equality predicates in IfaceType]` accordingly. We are now
      more careful to respect the properties of the
      `-fprint-explicit-kinds` and `-fprint-equality-relations` flags,
      which led to some improvements in error message outputs.
      Along the way, I also tweaked the error-reporting machinery not to
      print out the type of a typed hole when the type is an unlifted
      equality, since it's kind (`TYPE ('TupleRep '[])`) was more
      confusing than anything.
      Test Plan: make test TEST="T15039a T15039b T15039c T15039d"
      Reviewers: simonpj, goldfire, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15039
      Differential Revision: https://phabricator.haskell.org/D4696
  36. 14 May, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14875 by introducing PprPrec, and using it · 21e1a00c
      Ryan Scott authored
      Trying to determine when to insert parentheses during TH
      conversion is a bit of a mess. There is an assortment of functions
      that try to detect this, such as:
      * `hsExprNeedsParens`
      * `isCompoundHsType`
      * `hsPatNeedsParens`
      * `isCompoundPat`
      * etc.
      To make things worse, each of them have slightly different semantics.
      Plus, they don't work well in the presence of explicit type
      signatures, as #14875 demonstrates.
      All of these problems can be alleviated with the use of an explicit
      precedence argument (much like what `showsPrec` currently does). To
      accomplish this, I introduce a new `PprPrec` data type, and define
      standard predences for things like function application, infix
      operators, function arrows, and explicit type signatures (that last
      one is new). I then added `PprPrec` arguments to the various
      `-NeedsParens` functions, and use them to make smarter decisions
      about when things need to be parenthesized.
      A nice side effect is that functions like `isCompoundHsType` are
      now completely unneeded, since they're simply aliases for
      `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring
      to remove these sorts of functions. I also did a pass over various
      utility functions in GHC for constructing AST forms and used more
      appropriate precedences where convenient.
      Along the way, I also ripped out the existing `TyPrec`
      data type (which was tailor-made for pretty-printing `Type`s) and
      replaced it with `PprPrec` for consistency.
      Test Plan: make test TEST=T14875
      Reviewers: alanz, goldfire, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #14875
      Differential Revision: https://phabricator.haskell.org/D4688
  37. 07 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14238 by always pretty-printing visible tyvars · 718a0181
      Ryan Scott authored
      Before, GHC would never print visible tyvars in the absence
      of `-fprint-explicit-foralls`, which led to `:kind` displaying
      incorrect kinds in GHCi. The fix is simple—simply check beforehand
      if any of the type variable binders are required when deciding when
      to pretty-print them.
      Test Plan: make test TEST=T14238
      Reviewers: simonpj, goldfire, bgamari
      Subscribers: thomie, carter
      GHC Trac Issues: #14238
      Differential Revision: https://phabricator.haskell.org/D4564
  38. 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},