1. 22 Mar, 2019 1 commit
  2. 21 Mar, 2019 2 commits
    • Ömer Sinan Ağacan's avatar
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      
      ```haskell
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      ```
      
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      
      Fixes #11514.
      8d18a873
  3. 20 Mar, 2019 17 commits
  4. 16 Mar, 2019 2 commits
    • Simon Peyton Jones's avatar
      Add location to the extra-constraints wildcard · 600a1ac3
      Simon Peyton Jones authored
      The extra-constraints wildcard had lost its location
      (issue #16431).
      
      Happily this is easy to fix.  Lots of error improvements.
      600a1ac3
    • Simon Peyton Jones's avatar
      Improve error recovery in the typechecker · 4927117c
      Simon Peyton Jones authored
      Issue #16418 showed that we were carrying on too eagerly after a bogus
      type signature was identified (a bad telescope in fact), leading to a
      subsequent crash.
      
      This led me in to a maze of twisty little passages in the typechecker's
      error recovery, and I ended up doing some refactoring in TcRnMonad.
      Some specfifics
      
      * TcRnMonad.try_m is now called attemptM.
      
      * I switched the order of the result pair in tryTc,
        to make it consistent with other similar functions.
      
      * The actual exception used in the Tc monad is irrelevant so,
        to avoid polluting type signatures, I made tcTryM, a simple
        wrapper around tryM, and used it.
      
      The more important changes are in
      
      * TcSimplify.captureTopConstraints, where we should have been calling
        simplifyTop rather than reportUnsolved, so that levity defaulting
        takes place properly.
      
      * TcUnify.emitResidualTvConstraint, where we need to set the correct
        status for a new implication constraint.  (Previously we ended up
        with an Insoluble constraint wrapped in an Unsolved implication,
        which meant that insolubleWC gave the wrong answer.
      4927117c
  5. 15 Mar, 2019 3 commits
    • Simon Peyton Jones's avatar
      Report better suggestion for GADT data constructor · 97032ed9
      Simon Peyton Jones authored
      This addresses issue #16427. An easy fix.
      97032ed9
    • Ryan Scott's avatar
      Update Trac ticket URLs to point to GitLab · 610ec224
      Ryan Scott authored
      This moves all URL references to Trac tickets to their corresponding
      GitLab counterparts.
      610ec224
    • Ryan Scott's avatar
      Remove the GHCi debugger's panicking isUnliftedType check · 8162eab2
      Ryan Scott authored
      The GHCi debugger has never been that robust in the face of
      higher-rank types, or even types that are _interally_ higher-rank,
      such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
      however, things became even worse, as the debugger would start to
      _panic_ when a user tries passing the name of a higher-rank thing
      to `:print`. This all ties back to a strange `isUnliftedType` check
      in `Debugger` that was mysteriously added 11 years ago
      (in commit 4d71f5ee) with no
      explanation whatsoever.
      
      After some experimentation, no one is quite sure what this
      `isUnliftedType` check is actually accomplishing. The test suite
      still passes if it's removed, and I am unable to observe any
      differences in debugger before even with data types that _do_ have
      fields of unlifted types (e.g., `data T = MkT Int#`). Given that
      this is actively causing problems (see #14828), the prudent thing
      to do seems to be just removing this `isUnliftedType` check, and
      waiting to see if anyone shouts about it. This patch accomplishes
      just that.
      
      Note that this patch fix the underlying issues behind #14828, as the
      debugger will still print unhelpful info if you try this:
      
      ```
      λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
      λ> :print f
      f = (_t1::t1)
      ```
      
      But fixing this will require much more work, so let's start with the
      simple stuff for now.
      8162eab2
  6. 14 Mar, 2019 1 commit
  7. 13 Mar, 2019 2 commits
  8. 12 Mar, 2019 2 commits
  9. 11 Mar, 2019 2 commits
  10. 09 Mar, 2019 2 commits
    • Edward Z. Yang's avatar
      Make bkpcabal01 test compatible with new ordering requirements. · 6e3e537e
      Edward Z. Yang authored
      Previously, our test did something like this:
      
      1. Typecheck p
      2. Typecheck q (which made use of an instantiated p)
      3. Build instantiated p
      4. Build instantiated q
      
      Cabal previously permitted this, under the reasoning that during
      typechecking there's no harm in using the instantiated p even if we
      haven't build it yet; we'll just instantiate it on the fly with p.
      
      However, this is not true!  If q makes use of a Template Haskell
      splice from p, we absolutely must have built the instantiated p
      before we typecheck q, since this typechecking will need to
      run some splices.  Cabal now complains that you haven't done
      it correctly, which we indeed have not!
      
      Reordering so that we do this:
      
      1. Typecheck p
      3. Build instantiated p
      2. Typecheck q (which made use of an instantiated p)
      4. Build instantiated q
      
      Fixes the problem.  If Cabal had managed the ordering itself, it would
      have gotten it right.
      Signed-off-by: 's avatarEdward Z. Yang <ezyang@fb.com>
      6e3e537e
    • Simon Peyton Jones's avatar
      Stop inferring over-polymorphic kinds · 1f5cc9dc
      Simon Peyton Jones authored
      Before this patch GHC was trying to be too clever
      (Trac #16344); it succeeded in kind-checking this
      polymorphic-recursive declaration
      
          data T ka (a::ka) b
            = MkT (T Type           Int   Bool)
                  (T (Type -> Type) Maybe Bool)
      
      As Note [No polymorphic recursion] discusses, the "solution" was
      horribly fragile.  So this patch deletes the key lines in
      TcHsType, and a wodge of supporting stuff in the renamer.
      
      There were two regressions, both the same: a closed type family
      decl like this (T12785b) does not have a CUSK:
        type family Payload (n :: Peano) (s :: HTree n x) where
          Payload Z (Point a) = a
          Payload (S n) (a `Branch` stru) = a
      
      To kind-check the equations we need a dependent kind for
      Payload, and we don't get that any more.  Solution: make it
      a CUSK by giving the result kind -- probably a good thing anyway.
      
      The other case (T12442) was very similar: a close type family
      declaration without a CUSK.
      1f5cc9dc
  11. 08 Mar, 2019 5 commits
    • Roland Senn's avatar
    • Sylvain Henry's avatar
      TH: support raw bytes literals (#14741) · 224a6b86
      Sylvain Henry authored
      GHC represents String literals as ByteString internally for efficiency
      reasons. However, until now it wasn't possible to efficiently create
      large string literals with TH (e.g. to embed a file in a binary, cf #14741):
      TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack
      into a ByteString.
      
      This patch adds the possibility to efficiently create a "string" literal
      from raw bytes. We get the following compile times for different sizes
      of TH created literals:
      
      || Size || Before || After  || Gain ||
      || 30K  || 2.307s || 2.299  || 0%   ||
      || 3M   || 3.073s || 2.400s || 21%  ||
      || 30M  || 8.517s || 3.390s || 60%  ||
      
      Ticket #14741 can be fixed if the original code uses this new TH feature.
      224a6b86
    • Simon Peyton Jones's avatar
      Use captureTopConstraints in TcRnDriver calls · 5be7ad78
      Simon Peyton Jones authored
      Trac #16376 showed the danger of failing to report an error
      that exists only in the unsolved constraints, if an exception
      is raised (via failM).
      
      Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
      did just that -- i.e. it found errors in the constraints, and
      called failM to avoid a misleading cascade.
      
      So we need to be sure to call captureTopConstraints to report
      those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
      in TcRnDriver.tcRnType.
      
      As a result the error messages from test T13466 improved slightly,
      a happy outcome.
      5be7ad78
    • Vladislav Zavialov's avatar
      Testsuite: use 'fragile' instead of 'skip' for T3424, T14697 · 82628254
      Vladislav Zavialov authored
      Also, replace some tabs with spaces to avoid a "mixed indent" warning that vim
      gives me.
      82628254
    • Sebastian Graf's avatar
      Always do the worker/wrapper split for NOINLINEs · 1675d40a
      Sebastian Graf authored
      Trac #10069 revealed that small NOINLINE functions didn't get split
      into worker and wrapper. This was due to `certainlyWillInline`
      saying that any unfoldings with a guidance of `UnfWhen` inline
      unconditionally. That isn't the case for NOINLINE functions, so we
      catch this case earlier now.
      
      Nofib results:
      
      --------------------------------------------------------------------------------
              Program         Allocs    Instrs
      --------------------------------------------------------------------------------
       fannkuch-redux          -0.3%      0.0%
                   gg          +0.0%     +0.1%
             maillist          -0.2%     -0.2%
              minimax           0.0%     -0.8%
      --------------------------------------------------------------------------------
                  Min          -0.3%     -0.8%
                  Max          +0.0%     +0.1%
       Geometric Mean          -0.0%     -0.0%
      
      Fixes #10069.
      
      -------------------------
      Metric Increase:
          T9233
      -------------------------
      1675d40a
  12. 07 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16391 by using occCheckExpand in TcValidity · 068b7e98
      Ryan Scott authored
      The type-variables-escaping-their-scope-via-kinds check in
      `TcValidity` was failing to properly expand type synonyms, which led
      to #16391. This is easily fixed by using `occCheckExpand` before
      performing the validity check.
      
      Along the way, I refactored this check out into its own function,
      and sprinkled references to Notes to better explain all of the moving
      parts. Many thanks to @simonpj for the suggestions.
      
      Bumps the haddock submodule.
      068b7e98