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:
      
      ```hs
      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:
      
      ```hs
      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.
      d584e3f0
  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.
      f691f0c2
    • 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
      f93c9517.
      
      Fixes #16980
      
      Test cases: th/T16980{,a}
      9612e91c
    • 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.
      bf02c264
    • 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
      equalities.
      
      Unfortunately due to scoping issues, this will not solve #17208 for
      view patterns yet.
      397c6ed5
  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:
          T12234
          T12150
      b2577081
    • 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:
      
      ```hs
      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`.
      825c108b
  5. 05 Oct, 2019 2 commits
  6. 03 Oct, 2019 4 commits
  7. 01 Oct, 2019 6 commits
  8. 28 Sep, 2019 7 commits
  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
      so.
      
      Along the way, I did a little cleanup of the relevant code and
      documentation:
      
      * `enableCodeGenForUnboxedTuples` was only checking for the presence
        of `UnboxedTuples`, but `UnboxedSums` has the same complications.
        I fixed this and renamed the function to
        `enableCodeGenForUnboxedTuplesOrSums`.
      * I amended the users' guide with a discussion of these issues.
      4f81fab0
  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
          ...
      
      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
    • 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
      `GHC.Arr`.
      d90d0bad
    • 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
      time.
      
      -------------------------
      Metric Decrease:
          T11822
      -------------------------
      ebc65025
    • 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.
      2970dc7a
  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:
          ManyAlternatives
      
      Metric Increase:
          T11822
      -------------------------
      a7867c79
  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
      0dad81ca
    • Ben Gamari's avatar
      testsuite: Add test for #17202 · 2f8ce45a
      Ben Gamari authored
      2f8ce45a
    • Sylvain Henry's avatar
      Module hierarchy: Hs (#13009) · 51192964
      Sylvain Henry authored
      Add GHC.Hs module hierarchy replacing hsSyn.
      
      Metric Increase:
          haddock.compiler
      51192964
  15. 19 Sep, 2019 2 commits