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
      
      NoFib
      -----
      
      --------------------------------------------------------------------------------
              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
        platforms.
      - 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:
          T14683
      
      Metric Increase:
          T12150
          T12234
          T12425
          T13035
          T14683
          T5837
          T6048
      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>
      74ad75e8
  2. 14 Feb, 2020 1 commit
  3. 12 Feb, 2020 2 commits
  4. 11 Feb, 2020 1 commit
    • Richard Eisenberg's avatar
      Do not create nested quantified constraints · de32beff
      Richard Eisenberg authored
      Previously, we would accidentally make constraints like
      forall a. C a => forall b. D b => E a b c as we traversed
      superclasses. No longer!
      
      This patch also expands Note [Eagerly expand given superclasses]
      to work over quantified constraints; necessary for T16502b.
      
      Close #17202 and #16502.
      
      test cases: typecheck/should_compile/T{17202,16502{,b}}
      de32beff
  5. 08 Feb, 2020 1 commit
  6. 06 Feb, 2020 1 commit
  7. 31 Jan, 2020 2 commits
    • Andreas Klebinger's avatar
      A few optimizations in STG and Cmm parts: · 2a87a565
      Andreas Klebinger authored
      (Guided by the profiler output)
      
      - Add a few bang patterns, INLINABLE annotations, and a seqList in a few
        places in Cmm and STG parts.
      
      - Do not add external variables as dependencies in STG dependency
        analysis (GHC.Stg.DepAnal).
      2a87a565
    • Sylvain Henry's avatar
      Refactor package related code · 29c701c1
      Sylvain Henry authored
      The package terminology is a bit of a mess. Cabal packages contain
      components. Instances of these components when built with some
      flags/options/dependencies are called units. Units are registered into
      package databases and their metadata are called PackageConfig.
      
      GHC only knows about package databases containing units. It is a sad
      mismatch not fixed by this patch (we would have to rename parameters
      such as `package-id <unit-id>` which would affect users).
      
      This patch however fixes the following internal names:
      
      - Renames PackageConfig into UnitInfo.
      - Rename systemPackageConfig into globalPackageDatabase[Path]
      - Rename PkgConfXX into PkgDbXX
      - Rename pkgIdMap into unitIdMap
      - Rename ModuleToPkgDbAll into ModuleNameProvidersMap
      - Rename lookupPackage into lookupUnit
      - Add comments on DynFlags package related fields
      
      It also introduces a new `PackageDatabase` datatype instead of
      explicitly passing the following tuple: `(FilePath,[PackageConfig])`.
      
      The `pkgDatabase` field in `DynFlags` now contains the unit info for
      each unit of each package database exactly as they have been read from
      disk. Previously the command-line flag `-distrust-all-packages` would
      modify these unit info. Now this flag only affects the "dynamic"
      consolidated package state found in `pkgState` field. It makes sense
      because `initPackages` could be called first with this
      `distrust-all-packages` flag set and then again (using ghc-api) without
      and it should work (package databases are not read again from disk when
      `initPackages` is called the second time).
      
      Bump haddock submodule
      29c701c1
  8. 27 Jan, 2020 1 commit
  9. 25 Jan, 2020 2 commits
    • Sylvain Henry's avatar
      Module hierarchy: Cmm (cf #13009) · 6e2d9ee2
      Sylvain Henry authored
      6e2d9ee2
    • Sebastian Graf's avatar
      PmCheck: Formulate as translation between Clause Trees · 8038cbd9
      Sebastian Graf authored
      We used to check `GrdVec`s arising from multiple clauses and guards in
      isolation. That resulted in a split between `pmCheck` and
      `pmCheckGuards`, the implementations of which were similar, but subtly
      different in detail. Also the throttling mechanism described in
      `Note [Countering exponential blowup]` ultimately got quite complicated
      because it had to cater for both checking functions.
      
      This patch realises that pattern match checking doesn't just consider
      single guarded RHSs, but that it's always a whole set of clauses, each
      of which can have multiple guarded RHSs in turn. We do so by
      translating a list of `Match`es to a `GrdTree`:
      
      ```haskell
      data GrdTree
        = Rhs !RhsInfo
        | Guard !PmGrd !GrdTree      -- captures lef-to-right  match semantics
        | Sequence !GrdTree !GrdTree -- captures top-to-bottom match semantics
        | Empty                      -- For -XEmptyCase, neutral element of Sequence
      ```
      
      Then we have a function `checkGrdTree` that matches a given `GrdTree`
      against an incoming set of values, represented by `Deltas`:
      
      ```haskell
      checkGrdTree :: GrdTree -> Deltas -> CheckResult
      ...
      ```
      
      Throttling is isolated to the `Sequence` case and becomes as easy as one
      would expect: When the union of uncovered values becomes too big, just
      return the original incoming `Deltas` instead (which is always a
      superset of the union, thus a sound approximation).
      
      The returned `CheckResult` contains two things:
      
      1. The set of values that were not covered by any of the clauses, for
         exhaustivity warnings.
      2. The `AnnotatedTree` that enriches the syntactic structure of the
         input program with divergence and inaccessibility information.
      
      This is `AnnotatedTree`:
      
      ```haskell
      data AnnotatedTree
        = AccessibleRhs !RhsInfo
        | InaccessibleRhs !RhsInfo
        | MayDiverge !AnnotatedTree
        | SequenceAnn !AnnotatedTree !AnnotatedTree
        | EmptyAnn
      ```
      
      Crucially, `MayDiverge` asserts that the tree may force diverging
      values, so not all of its wrapped clauses can be redundant.
      
      While the set of uncovered values can be used to generate the missing
      equations for warning messages, redundant and proper inaccessible
      equations can be extracted from `AnnotatedTree` by
      `redundantAndInaccessibleRhss`.
      
      For this to work properly, the interface to the Oracle had to change.
      There's only `addPmCts` now, which takes a bag of `PmCt`s. There's a
      whole bunch of `PmCt` variants to replace the different oracle functions
      from before.
      
      The new `AnnotatedTree` structure allows for more accurate warning
      reporting (as evidenced by a number of changes spread throughout GHC's
      code base), thus we fix #17465.
      
      Fixes #17646 on the go.
      
      Metric Decrease:
          T11822
          T9233
          PmSeriesS
          haddock.compiler
      8038cbd9
  10. 13 Jan, 2020 2 commits
  11. 08 Jan, 2020 2 commits
  12. 06 Jan, 2020 1 commit
  13. 04 Jan, 2020 1 commit
  14. 31 Dec, 2019 1 commit
  15. 20 Dec, 2019 1 commit
    • Ryan Scott's avatar
      lookupBindGroupOcc: recommend names in the same namespace (#17593) · 70e56b27
      Ryan Scott authored
      Previously, `lookupBindGroupOcc`'s error message would recommend all
      similar names in scope, regardless of whether they were type
      constructors, data constructors, or functions, leading to the
      confusion witnessed in #17593. This is easily fixed by only
      recommending names in the same namespace, using the
      `nameSpacesRelated` function.
      
      Fixes #17593.
      70e56b27
  16. 17 Dec, 2019 3 commits
  17. 11 Dec, 2019 1 commit
    • Ryan Scott's avatar
      Ignore unary constraint tuples during typechecking (#17511) · 921d3238
      Ryan Scott authored
      We deliberately avoid defining a magical `Unit%` class, for reasons
      that I have expounded upon in the newly added
      `Note [Ignore unary constraint tuples]` in `TcHsType`. However, a
      sneaky user could try to insert `Unit%` into their program by way of
      Template Haskell, leading to the interface-file error observed
      in #17511. To avoid this, any time we encounter a unary constraint
      tuple during typechecking, we drop the surrounding constraint tuple
      application. This is safe to do since `Unit% a` and `a` would be
      semantically equivalent (unlike other forms of unary tuples).
      
      Fixes #17511.
      921d3238
  18. 07 Dec, 2019 1 commit
    • Simon Peyton Jones's avatar
      Split up coercionKind · 0a4ca9eb
      Simon Peyton Jones authored
      This patch implements the idea in #17515, splitting `coercionKind` into:
      
       * `coercion{Left,Right}Kind`, which computes the left/right side of the
          pair
       * `coercionKind`, which computes the pair of coercible types
      
      This is reduces allocation since we frequently only need only one side
      of the pair. Specifically, we see the following improvements on x86-64
      Debian 9:
      
      | test     | new        | old           | relative chg. |
      | :------- | ---------: | ------------: | ------------: |
      | T5030	   | 695537752  | 747641152.0   | -6.97%        |
      | T5321Fun | 449315744  | 474009040.0   | -5.21%        |
      | T9872a   | 2611071400 | 2645040952.0  | -1.28%        |
      | T9872c   | 2957097904 | 2994260264.0  | -1.24%        |
      | T12227   | 773435072  | 812367768.0   | -4.79%        |
      | T12545   | 3142687224 | 3215714752.0  | -2.27%        |
      | T14683   | 9392407664 | 9824775000.0  | -4.40%        |
      
      Metric Decrease:
          T12545
          T9872a
          T14683
          T5030
          T12227
          T9872c
          T5321Fun
          T9872b
      0a4ca9eb
  19. 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
      position:
      
         F * * *   becomes  F (*) (*) (*)
         F A * B   becomes  F A (*) B
         Proxy *   becomes  Proxy (*)
         a * -> *  becomes  a (*) -> *
      3354c68e
  20. 04 Dec, 2019 1 commit
    • Ben Gamari's avatar
      Simplify uniqAway · 78b67ad0
      Ben Gamari authored
      This does two things:
      
       * Eliminate all uses of Unique.deriveUnique, which was quite easy to
         mis-use and extremely subtle.
      
       * Rename the previous "derived unique" notion to "local unique". This
         is possible because the only places where `uniqAway` can be safely
         used are those where local uniqueness (with respect to some
         InScopeSet) is sufficient.
      
       * Rework the implementation of VarEnv.uniqAway, as discussed in #17462.
         This should make the operation significantly more efficient than its
         previous iterative implementation..
      
      Metric Decrease:
          T9872c
          T12227
          T9233
          T14683
          T5030
          T12545
          hie002
      
      Metric Increase:
          T9961
      78b67ad0
  21. 02 Dec, 2019 1 commit
  22. 30 Nov, 2019 2 commits
  23. 28 Nov, 2019 2 commits
    • Brian Wignall's avatar
      3748ba3a
    • Philipp Krüger's avatar
      Reduce boolean blindness in OccInfo(OneOcc) #17482 · 5f84b52a
      Philipp Krüger authored
      * Transformed the type aliases `InterestingCxt`, `InsideLam` and `OneBranch`
        into data types.
      * Added Semigroup and Monoid instances for use in orOccInfo in OccurAnal.hs
      * Simplified some usage sites by using pattern matching instead of boolean algebra.
      
      Metric Increase:
          T12150
      
      This increase was on a Mac-build of exactly 1%. This commit does *not* re-intruduce
      the asymptotic memory usage described in T12150.
      5f84b52a
  24. 24 Nov, 2019 1 commit
  25. 19 Nov, 2019 2 commits
    • Ben Gamari's avatar
      Give seq a more precise type and remove magic · 08d595c0
      Ben Gamari authored
      `GHC.Prim.seq` previously had the rather plain type:
      
          seq :: forall a b. a -> b -> b
      
      However, it also had a special typing rule to applications
      where `b` is not of kind `Type`.
      
      Issue #17440 noted that levity polymorphism allows us to rather give
      it the more precise type:
      
          seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b
      
      This allows us to remove the special typing rule that we previously
      required to allow applications on unlifted arguments. T9404 contains a
      non-Type application of `seq` which should verify that this works as
      expected.
      
      Closes #17440.
      08d595c0
    • Alex D's avatar
      Optimize MonadUnique instances based on IO (#16843) · 88013b78
      Alex D authored
      Metric Decrease:
          T14683
      88013b78
  26. 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
  27. 01 Nov, 2019 1 commit
  28. 16 Oct, 2019 1 commit
    • Richard Eisenberg's avatar
      Break up TcRnTypes, among other modules. · 51fad9e6
      Richard Eisenberg authored
      This introduces three new modules:
      
       - basicTypes/Predicate.hs describes predicates, moving
         this logic out of Type. Predicates don't really exist
         in Core, and so don't belong in Type.
      
       - typecheck/TcOrigin.hs describes the origin of constraints
         and types. It was easy to remove from other modules and
         can often be imported instead of other, scarier modules.
      
       - typecheck/Constraint.hs describes constraints as used in
         the solver. It is taken from TcRnTypes.
      
      No work other than module splitting is in this patch.
      
      This is the first step toward homogeneous equality, which will
      rely more strongly on predicates. And homogeneous equality is the
      next step toward a dependently typed core language.
      51fad9e6
  29. 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
          ...
      
      Limitations
      -----------
      
      * '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.
      0b5eede9
  30. 20 Sep, 2019 1 commit
    • Simon Peyton Jones's avatar
      Fix bogus type of case expression · 0dad81ca
      Simon Peyton Jones authored
      Issue #17056 revealed that we were sometimes building a case
      expression whose type field (in the Case constructor) was bogus.
      
      Consider a phantom type synonym
         type S a = Int
      and we want to form the case expression
         case x of K (a::*) -> (e :: S a)
      We must not make the type field of the Case constructor be (S a)
      because 'a' isn't in scope.  We must instead expand the synonym.
      
      Changes in this patch:
      
      * Expand synonyms in the new function CoreUtils.mkSingleAltCase.
      
      * Use mkSingleAltCase in MkCore.wrapFloat, which was the proximate
        source of the bug (when called by exprIsConApp_maybe)
      
      * Use mkSingleAltCase elsewhere
      
      * Documentation
          CoreSyn   new invariant (6) in Note [Case expression invariants]
          CoreSyn   Note [Why does Case have a 'Type' field?]
          CoreUtils Note [Care with the type of a case expression]
      
      * I improved Core Lint's error reporting, which was pretty
        confusing in this case, because it didn't mention that the offending
        type was the return type of a case expression.
      
      * A little bit of cosmetic refactoring in CoreUtils
      0dad81ca