1. 12 Feb, 2020 2 commits
  2. 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}}
  3. 08 Feb, 2020 1 commit
  4. 06 Feb, 2020 1 commit
  5. 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).
    • 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
  6. 27 Jan, 2020 1 commit
  7. 25 Jan, 2020 2 commits
    • Sylvain Henry's avatar
      Module hierarchy: Cmm (cf #13009) · 6e2d9ee2
      Sylvain Henry authored
    • 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`:
      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`:
      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`:
      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
      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:
  8. 13 Jan, 2020 2 commits
  9. 08 Jan, 2020 2 commits
  10. 06 Jan, 2020 1 commit
  11. 04 Jan, 2020 1 commit
  12. 31 Dec, 2019 1 commit
  13. 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.
  14. 17 Dec, 2019 3 commits
  15. 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.
  16. 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
       * `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:
  17. 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 (*) -> *
  18. 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:
      Metric Increase:
  19. 02 Dec, 2019 1 commit
  20. 30 Nov, 2019 2 commits
  21. 28 Nov, 2019 2 commits
    • Brian Wignall's avatar
    • 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:
      This increase was on a Mac-build of exactly 1%. This commit does *not* re-intruduce
      the asymptotic memory usage described in T12150.
  22. 24 Nov, 2019 1 commit
  23. 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
      Closes #17440.
    • Alex D's avatar
      Optimize MonadUnique instances based on IO (#16843) · 88013b78
      Alex D authored
      Metric Decrease:
  24. 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:
  25. 01 Nov, 2019 1 commit
  26. 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.
  27. 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.
  28. 20 Sep, 2019 2 commits
    • 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
    • Sylvain Henry's avatar
      Module hierarchy: Hs (#13009) · 51192964
      Sylvain Henry authored
      Add GHC.Hs module hierarchy replacing hsSyn.
      Metric Increase:
  29. 16 Sep, 2019 1 commit
    • Sebastian Graf's avatar
      Encode shape information in `PmOracle` · 7915afc6
      Sebastian Graf authored
      Previously, we had an elaborate mechanism for selecting the warnings to
      generate in the presence of different `COMPLETE` matching groups that,
      albeit finely-tuned, produced wrong results from an end user's
      perspective in some cases (#13363).
      The underlying issue is that at the point where the `ConVar` case has to
      commit to a particular `COMPLETE` group, there's not enough information
      to do so and the status quo was to just enumerate all possible complete
      sets nondeterministically.  The `getResult` function would then pick the
      outcome according to metrics defined in accordance to the user's guide.
      But crucially, it lacked knowledge about the order in which affected
      clauses appear, leading to the surprising behavior in #13363.
      In !1010 we taught the term oracle to reason about literal values a
      variable can certainly not take on. This MR extends that idea to
      `ConLike`s and thereby fixes #13363: Instead of committing to a
      particular `COMPLETE` group in the `ConVar` case, we now split off the
      matching constructor incrementally and record the newly covered case as
      a refutable shape in the oracle. Whenever the set of refutable shapes
      covers any `COMPLETE` set, the oracle recognises vacuosity of the
      uncovered set.
      This patch goes a step further: Since at this point the information
      in value abstractions is merely a cut down representation of what the
      oracle knows, value abstractions degenerate to a single `Id`, the
      semantics of which is determined by the oracle state `Delta`.
      Value vectors become lists of `[Id]` given meaning to by a single
      `Delta`, value set abstractions (of which the uncovered set is an
      instance) correspond to a union of `Delta`s which instantiate the
      same `[Id]` (akin to models of formula).
      Fixes #11528 #13021, #13363, #13965, #14059, #14253, #14851, #15753, #17096, #17149
      Metric Decrease: