1. 12 Oct, 2019 1 commit
  2. 09 Oct, 2019 1 commit
    • Ryan Scott's avatar
      Use addUsedDataCons more judiciously in TcDeriv (#17324) · d584e3f0
      Ryan Scott authored
      If you derive an instance like this:
      deriving <...> instance Foo C
      And the data constructors for `C` aren't in scope, then
      `doDerivInstErrorChecks1` throws an error. Moreover, it will
      _only_ throw an error if `<...>` is either `stock` or `newtype`.
      This is because the code that the `anyclass` or `via` strategies
      would generate would not require the use of the data constructors
      for `C`.
      However, `doDerivInstErrorChecks1` has another purpose. If you
      write this:
      import M (C(MkC1, ..., MkCn))
      deriving <...> instance Foo C
      Then `doDerivInstErrorChecks1` will call `addUsedDataCons` on
      `MkC1` through `MkCn` to ensure that `-Wunused-imports` does not
      complain about them. However, `doDerivInstErrorChecks1` was doing
      this for _every_ deriving strategy, which mean that if `<...>` were
      `anyclass` or `via`, then the warning about `MkC1` through `MkCn`
      being unused would be suppressed!
      The fix is simple enough: only call `addUsedDataCons` when the
      strategy is `stock` or `newtype`, just like the other code paths
      in `doDerivInstErrorChecks1`.
      Fixes #17324.
  3. 08 Oct, 2019 4 commits
    • Sebastian Graf's avatar
      PmCheck: Look up parent data family TyCon when populating `PossibleMatches` · f691f0c2
      Sebastian Graf authored
      The vanilla COMPLETE set is attached to the representation TyCon of a
      data family instance, whereas the user-defined COMPLETE sets are
      attached to the parent data family TyCon itself.
      Previously, we weren't trying particularly hard to get back to the
      representation TyCon to the parent data family TyCon, resulting in bugs
      like #17207. Now we should do much better.
      Fixes the original issue in #17207, but I found another related bug that
      isn't so easy to fix.
    • Richard Eisenberg's avatar
      Solve constraints from top-level groups sooner · 9612e91c
      Richard Eisenberg authored
      Previously, all constraints from all top-level groups (as
      separated by top-level splices) were lumped together and solved
      at the end. This could leak metavariables to TH, though, and
      that's bad. This patch solves each group's constraints before
      running the next group's splice.
      Naturally, we now report fewer errors in some cases.
      One nice benefit is that this also fixes #11680, but in a much
      simpler way than the original fix for that ticket. Admittedly,
      the error messages degrade just a bit from the fix from #11680
      (previously, we informed users about variables that will be
      brought into scope below a top-level splice, and now we just
      report an out-of-scope error), but the amount of complexity
      required throughout GHC to get that error was just not worth it.
      This patch thus reverts much of
      Fixes #16980
      Test cases: th/T16980{,a}
    • Ryan Scott's avatar
      Mark newtype constructors as used in the Coercible solver (#10347) · bf02c264
      Ryan Scott authored
      Currently, newtype constructors are not marked as used when they are
      accessed under the hood by uses of `coerce`, as described in #10347.
      This fixes #10347 by co-opting the `tcg_keep` field of `TcGblEnv`
      to track uses of newtype constructors in the `Coercible` solver.
      See `Note [Tracking unused binding and imports]` in `TcRnTypes`.
      Since #10347 is fixed, I was able to simplify the code in `TcDeriv`
      slightly, as the hack described in
      `Note [Newtype deriving and unused constructors]`
      is no longer necessary.
    • Sebastian Graf's avatar
      PmCheck: Identify some semantically equivalent expressions · 397c6ed5
      Sebastian Graf authored
      By introducing a `CoreMap Id` to the term oracle, we can represent
      syntactically equivalent expressions by the same `Id`. Combine that with
      `CoreOpt.simpleCoreExpr` and it might even catch non-trivial semantic
      Unfortunately due to scoping issues, this will not solve #17208 for
      view patterns yet.
  4. 07 Oct, 2019 2 commits
    • Ben Gamari's avatar
      Refactor, document, and optimize LLVM configuration loading · b2577081
      Ben Gamari authored
      As described in the new Note [LLVM Configuration] in SysTools, we now
      load llvm-targets and llvm-passes lazily to avoid the overhead of doing
      so when -fllvm isn't used (also known as "the common case").
      Noticed in #17003.
      Metric Decrease:
    • Ryan Scott's avatar
      Only flatten up to type family arity in coreFlattenTyFamApp (#16995) · 825c108b
      Ryan Scott authored
      Among other uses, `coreFlattenTyFamApp` is used by Core Lint as a
      part of its check to ensure that each type family axiom reduces
      according to the way it is defined in the source code. Unfortunately,
      the logic that `coreFlattenTyFamApp` uses to flatten type family
      applications disagreed with the logic in `TcFlatten`, which caused
      it to spuriously complain this program:
      type family Param :: Type -> Type
      type family LookupParam (a :: Type) :: Type where
        LookupParam (f Char) = Bool
        LookupParam x        = Int
      foo :: LookupParam (Param ())
      foo = 42
      This is because `coreFlattenTyFamApp` tries to flatten the `Param ()`
      in `LookupParam (Param ())` to `alpha` (where `alpha` is a flattening
      skolem), and GHC is unable to conclude that `alpha` is apart from
      `f Char`. This patch spruces up `coreFlattenTyFamApp` so that it
      instead flattens `Param ()` to `alpha ()`, which GHC _can_ know for
      sure is apart from `f Char`. See
      `Note [Flatten], wrinkle 3` in `FamInstEnv`.
  5. 05 Oct, 2019 2 commits
  6. 03 Oct, 2019 4 commits
  7. 01 Oct, 2019 6 commits
    • Ömer Sinan Ağacan's avatar
      Make small INLINE functions behave properly · 8924224e
      Ömer Sinan Ağacan authored
      Simon writes:
      Currently we check for a type arg rather than isTyCoArg.   This in turn
      makes INLINE things look bigger than they should be, and stops them
      being inlined into boring contexts when they perfectly well could be.
          f x = g <refl> x
          {-# INLINE g #-}
          ... (map (f x) xs) ...
      The context is boring, so don't inline unconditionally.  But f's RHS is
      no bigger than its call, provided you realise that the coercion argument
      is ultimately cost-free.
      This happens in practice for $WHRefl. It's not a big deal: at most it
      means we have an extra function call overhead.  But it's untidy, and
      actually worse than what happens without an INLINE pragma.
      Fixes #17182
      This makes 0.0% change in nofib binary sizes.
    • Sebastian Graf's avatar
      Add testcases inspired by Luke Maranget's pattern match series · 58013220
      Sebastian Graf authored
      In his paper "Warnings for Pattern Matching", Luke Maranget describes
      three series in his appendix for which GHC's pattern match checker
      scaled very badly. We mostly avoid this now with !1752. This commit adds
      regression tests for each of the series.
      Fixes #17264.
    • Sebastian Graf's avatar
      Add a bunch of testcases for the pattern match checker · 6548b7b0
      Sebastian Graf authored
      Adds regression tests for tickets #17207, #17208, #17215, #17216,
       #17218, #17219, #17248
    • Ben Gamari's avatar
      testsuite: Mark T3389 as broken in hpc way on i386 · dbdf6a3d
      Ben Gamari authored
      See #17256.
    • Takenobu Tani's avatar
      testsuite: Add minimal test for :doc command · b36dd49b
      Takenobu Tani authored
      Currently, there are no testcases for GHCi `:doc` command.
      Perhaps because it was experimental. And it could be changed in the future.
      But `:doc` command is already useful, so I add a minimal regression test
      to keep current behavior.
      See also 85309a3c for implementation of `:doc` command.
    • Sebastian Graf's avatar
  8. 28 Sep, 2019 7 commits
    • Sebastian Graf's avatar
      PmCheck: No ConLike instantiation in pmcheck · c5d888d4
      Sebastian Graf authored
      `pmcheck` used to call `refineToAltCon` which would refine the knowledge
      we had about a variable by equating it to a `ConLike` application.
      Since we weren't particularly smart about this in the Check module, we
      simply freshened the constructors existential and term binders utimately
      through a call to `mkOneConFull`.
      But that instantiation is unnecessary for when we match against a
      concrete pattern! The pattern will already have fresh binders and field
      types. So we don't call `refineToAltCon` from `Check` anymore.
      Subsequently, we can simplify a couple of call sites and functions in
      `PmOracle`. Also implementing `computeCovered` becomes viable and we
      don't have to live with the hack that was `addVarPatVecCt` anymore.
      A side-effect of not indirectly calling `mkOneConFull` anymore is that
      we don't generate the proper strict argument field constraints anymore.
      Instead we now desugar ConPatOuts as if they had bangs on their strict
      fields. This implies that `PmVar` now carries a `HsImplBang` that we
      need to respect by a (somewhat ephemeral) non-void check. We fix #17234
      in doing so.
    • Ben Gamari's avatar
      testsuite: Mark TH tests as fragile in LLVM built external-interpreter · 6f9fa0be
      Ben Gamari authored
      Due to #16087. This drops the previous explicit list of broken tests and rather
      encompasses the entire set of tests since they all appear to be broken.
    • Ben Gamari's avatar
      testsuite: Mark T3389 as broken in profiled ways on i386 · ad2a1f99
      Ben Gamari authored
      As noted in #17256.
    • Ben Gamari's avatar
      testsuite: Mark hs_try_putmvar003 as fragile in threaded1 · bb984ac6
      Ben Gamari authored
      Due to #16361. Note that I'm leaving out threaded2 since it's not clear
      whether the single crash in that way was due to other causes.
    • Ben Gamari's avatar
      testsuite: Mark cgrun071 as broken on i386 · 0b1fa64d
      Ben Gamari authored
      As described in #17247.
    • Shayne Fletcher's avatar
    • Sebastian Graf's avatar
      PmCheck: Look at precendence to give type signatures to some wildcards · 1582dafa
      Sebastian Graf authored
      Basically do what we currently only do for -XEmptyCase in other cases
      where adding the type signature won't distract from pattern
      matches in other positions.
      We use the precedence to guide us, equating "need to parenthesise" with
      "too much noise".
  9. 26 Sep, 2019 1 commit
    • Ryan Scott's avatar
      Make -fbyte-code prevent unboxed tuples/sums from implying object code (#16876) · 4f81fab0
      Ryan Scott authored
      This resolves #16876 by making the explicit use of `-fbyte-code`
      prevent code that enables `UnboxedTuples` or `UnboxedSums` from
      automatically compiling to object code. This allows for a nice
      middle ground where most code that enables `UnboxedTuples`/-`Sums`
      will still benefit from automatically enabling `-fobject-code`, but
      allows power users who wish to avoid this behavior in certain corner
      cases (such as `lens`, whose use case is documented in #16876) to do
      Along the way, I did a little cleanup of the relevant code and
      * `enableCodeGenForUnboxedTuples` was only checking for the presence
        of `UnboxedTuples`, but `UnboxedSums` has the same complications.
        I fixed this and renamed the function to
      * I amended the users' guide with a discussion of these issues.
  10. 25 Sep, 2019 4 commits
    • 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.
    • Ben Gamari's avatar
      base: Move Ix typeclass to GHC.Ix · d90d0bad
      Ben Gamari authored
      The `Ix` class seems rather orthogonal to its original home in
    • Sebastian Graf's avatar
      PmCheck: Only ever check constantly many models against a single pattern · ebc65025
      Sebastian Graf authored
      Introduces a new flag `-fmax-pmcheck-deltas` to achieve that. Deprecates
      the old `-fmax-pmcheck-iter` mechanism in favor of this new flag.
      From the user's guide:
      Pattern match checking can be exponential in some cases. This limit makes sure
      we scale polynomially in the number of patterns, by forgetting refined
      information gained from a partially successful match. For example, when
      matching `x` against `Just 4`, we split each incoming matching model into two
      sub-models: One where `x` is not `Nothing` and one where `x` is `Just y` but
      `y` is not `4`. When the number of incoming models exceeds the limit, we
      continue checking the next clause with the original, unrefined model.
      This also retires the incredibly hard to understand "maximum number of
      refinements" mechanism, because the current mechanism is more general
      and should catch the same exponential cases like PrelRules at the same
      Metric Decrease:
    • Kari Pahula's avatar
      Add -Wderiving-defaults (#15839) · 2970dc7a
      Kari Pahula authored
      Enabling both DeriveAnyClass and GeneralizedNewtypeDeriving can cause
      a warning when no explicit deriving strategy is in use. This change adds
      an enable/suppress flag for it.
  11. 24 Sep, 2019 1 commit
  12. 23 Sep, 2019 1 commit
  13. 21 Sep, 2019 1 commit
    • Sebastian Graf's avatar
      Get rid of PmFake · a7867c79
      Sebastian Graf authored
      The pattern match oracle can now cope with the abundance of information
      that ViewPatterns, NPlusKPats, overloaded lists, etc. provide.
      No need to have PmFake anymore!
      Also got rid of a spurious call to `allCompleteMatches`, which we used to call
      *for every constructor* match. Naturally this blows up quadratically for
      programs like `ManyAlternatives`.
      Metric Decrease:
      Metric Increase:
  14. 20 Sep, 2019 3 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
    • Ben Gamari's avatar
      testsuite: Add test for #17202 · 2f8ce45a
      Ben Gamari authored
    • Sylvain Henry's avatar
      Module hierarchy: Hs (#13009) · 51192964
      Sylvain Henry authored
      Add GHC.Hs module hierarchy replacing hsSyn.
      Metric Increase:
  15. 19 Sep, 2019 2 commits