1. 06 Dec, 2016 1 commit
  2. 05 Dec, 2016 2 commits
    • Simon Peyton Jones's avatar
      Test Trac #12925 · 3e3f7c21
      Simon Peyton Jones authored
      3e3f7c21
    • Simon Peyton Jones's avatar
      Fix an asymptotic bug in the occurrence analyser · 517d03e4
      Simon Peyton Jones authored
      Trac #12425 and #12234 showed up a major and long-standing
      bug in the occurrence analyser, whereby it could generate
      explonentially large program!
      
      There's a lot of commentary on #12425; and it's all described
      in Note [Loop breakers, node scoring, and stability]
      
      I did quite a lot of refactoring to make the code comprehensibe
      again (its structure had bit-rotted rather), so the patch
      looks bigger than it really is.
      
      Hurrah!
      
      I did a nofib run to check that I hadn't inadertently ruined
      anything:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                fluid          -0.3%     -1.5%      0.01      0.01     +0.0%
               parser          -0.9%     +0.6%      0.04      0.04     +0.0%
               prolog          -0.1%     +1.2%      0.00      0.00     +0.0%
      
      --------------------------------------------------------------------------------
                  Min          -0.9%     -1.5%     -8.6%     -8.7%     +0.0%
                  Max          +0.1%     +1.2%     +7.7%     +7.8%     +2.4%
       Geometric Mean          -0.2%     -0.0%     -0.2%     -0.3%     +0.0%
      
      I checked what happened in 'prolog'.  It seems that we have a
      recursive data structure something like this
      
         f :: [blah]
         f x = build (\cn.  ...g...  )
      
         g :: [blah2]
         g y = ....(foldr k z (f y))....
      
      If we inline 'f' into 'g' we get better fusion than the other
      way round, but we don't have any way to spot that at the moment.
      (I wonder if we could do worker/wrapper for functions returning
      a 'build'?)  It was happening before by a fluke.
      
      Anyway I decided to accept this; it's relatively rare I think.
      517d03e4
  3. 17 Nov, 2016 1 commit
    • Edward Z. Yang's avatar
      Test for type synonym loops on TyCon. · 31398fbc
      Edward Z. Yang authored
      
      
      Summary:
      Previously, we tested for type synonym loops by doing
      a syntactic test on the literal type synonym declarations.
      However, in some cases, loops could go through hs-boot
      files, leading to an infinite loop (#12042); a similar
      situation can occur when signature merging.
      
      This commit replaces the syntactic test with a test on
      TyCon, simply by walking down all type synonyms until
      we bottom out, or find we've looped back.  It's a lot
      simpler.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2656
      
      GHC Trac Issues: #12042
      31398fbc
  4. 02 Nov, 2016 1 commit
  5. 26 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fundeps work even for unary type classes · 801c2637
      Simon Peyton Jones authored
      The functional-dependency improvement functions,
         improveFromAnother
         improveFromInstEnv
      had a side-condition that said the type class has to have at
      least two arguments.  But not so, as Trac #12763 shows:
      
         class C a | -> a where ...
      
      is perfectly legal, albeit a bit of a corner case.
      801c2637
  6. 24 Oct, 2016 1 commit
    • Simon Peyton Jones's avatar
      Prioritise class-level equality costraints · 1c4a39d3
      Simon Peyton Jones authored
      This patch fixes Trac #12734 by prioritising the class-level
      variants of equality constraints, namely (a~b) and (a~~b).
      
      See comment:10 of Trac #12734 for a description of what
      went wrong, and Note [Prioritise class equalities] in TcSMonad.
      
      The fix is still not great, but it's a definite step forward, and
      cures the particular problem.
      
      Worth merging to 8.0.
      1c4a39d3
  7. 21 Oct, 2016 2 commits
    • Simon Peyton Jones's avatar
      Test Trac #12507 · cdbc73ae
      Simon Peyton Jones authored
      This is now working apparently.  It relates to when a
      polymorphic function gets instantiated, under some
      implicit paramter bindings.
      cdbc73ae
    • Simon Peyton Jones's avatar
      Refactor typechecking of pattern bindings · 45bfd1a6
      Simon Peyton Jones authored
      This patch fixes a regression introduced, post 8.0.1, by
      this major commit:
      
           commit 15b9bf4b
           Author: Simon Peyton Jones <simonpj@microsoft.com>
           Date:   Sat Jun 11 23:49:27 2016 +0100
      
               Improve typechecking of let-bindings
      
               This major commit was initially triggered by #11339, but it
               spiraled into a major review of the way in which type
               signatures for bindings are handled, especially partial type
               signatures.
      
      I didn't get the typechecking of pattern bindings right, leading
      to Trac #12427.
      
      In fixing this I found that this program doesn't work:
      
        data T where
          T :: a -> ((forall b. [b]->[b]) -> Int) -> T
      
        h1 y = case y of T _ v -> v
      
      Works in 7.10, but not in 8.0.1.
      
      There's a happy ending. I found a way to fix this, and improve
      pattern bindings too.  Not only does this fix #12427, but it also
      allows
      
      In particular,we now can accept
      
        data T where MkT :: a -> Int -> T
      
        ... let { MkT _ q = t } in ...
      
      Previously this elicited "my head exploded" but it's really
      fine since q::Int.
      
      The approach is described in detail in TcBinds
         Note [Typechecking pattern bindings]
      Super cool.  And not even a big patch!
      45bfd1a6
  8. 17 Oct, 2016 1 commit
  9. 08 Oct, 2016 2 commits
  10. 30 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Fix impredicativity (again) · b612da66
      Simon Peyton Jones authored
      This patch fixes Trac #12616.
      
      Dignosis.  In TcUnify.tc_sub_type_ds we were going to some trouble to
      support co- and contra-variance even for impredicative types.  With
      -XImpredicativeTYpes, this allowed a unification variable to be
      unified with a polytype (probably wrongly) and that caused later
      trouble in the constraint solver, where -XImpredicativeTypes was /not/
      on.  In effect, -XImpredicativeTypes can't be switched on locally.
      
      Why did we want ImpredicativeTypes locally?  Because the program
      generated by GND for a higher-rank method involved impredicative
      instantation of 'coerce':
            op = coerce op   -- where op has a higher rank type
      See Note [Newtype-deriving instances] in TcGenDeriv.
      
      Cure.
      
      1.  It is ghastly to rely on ImpredicativeTypes (a 100% flaky
          feature) to instantiate coerce polymorphically.  Happily we
          now have Visible Type Application, so I've used that instead
          which should be solid and reliable.
      
      2.  I deleted the code in tc_sub_type_ds that allows the constraint
          solver to "look through" a unification variable to find a
          polytype.  That used to be essential in the days of ReturnTv,
          but it's utterly unreliable and should be consigned to the dustbin
          of history.  (We have ExpType now for the essential uses.)
      
      Tests involving ImpredicativeTypes are affected, but I'm not worried
      about them... it's advertised as a feature you can't rely on, and
      I want to reform it outright.
      b612da66
  11. 12 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Be less picky about reporing inaccessible code · 03541cba
      Simon Peyton Jones authored
      Triggered by the discussion on Trac #12466, this patch
      makes GHC less aggressive about reporting an error when
      there are insoluble Givens.
      
      Being so agressive was making some libraries fail to
      compile, and is arguably wrong in at least some cases.
      See the discussion on the ticket.
      
      Several test now pass when they failed before; see
      the files-modified list for this patch.
      03541cba
  12. 31 Aug, 2016 2 commits
  13. 21 Aug, 2016 1 commit
    • Edward Z. Yang's avatar
      Axe initIfaceTc, tie the knot through HPT (or if_rec_types). · e907e1f1
      Edward Z. Yang authored
      
      
      Summary:
      initIfaceTc was originally used to make sure when we typecheck
      an interface, it can find the TyThings for things it itself
      defined.  However, in the case of retypecheckLoop, this wasn't
      necessary because we ALREADY tied the knot through the HPT.
      
      This commit removes initIfaceTc, instead relying on the HPT
      to tie the knot.  genModDetails' caller needed to be modified
      to tie the knot, but there are not that many call-sites of
      typecheckIface so the change is quite reasonable.
      
      We also introduce a new 'initIfaceLoad', which does
      NOT set up 'if_rec_types'.  It's used when we're
      typechecking old, up-to-date interfaces in, since we're
      never going to update the type environment.
      
      The full details are in Note [Knot-tying typecheckIface].
      Displeasingly, we need a special case to handle DFuns in
      the case of tcHiBootIface, see
      Note [DFun knot-tying special case] for the gory details.
      
      I also added another test which tickles a bug in a buggy
      version of this patch (see "Why the seq?")
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2349
      e907e1f1
  14. 20 Jul, 2016 2 commits
  15. 05 Jul, 2016 1 commit
  16. 29 Jun, 2016 1 commit
  17. 28 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Deal correctly with unused imports for 'coerce' · 23b80ac4
      Simon Peyton Jones authored
      We only do newtype unwrapping for Coercible constraints if
      the newtype's data constructor is in scope.  We were trying to
      record the fact that the data constructor was thereby 'used', so
      that an import statement would not be flagged as unnecsssary
      (by -Wunused-imports).
      
      But the code was simply wrong. It was wrong because it assumed
      that only one level of unwrapping happened, whereas
      tcTopNormaliseNewTypeTF_maybe actually unwraps multiple layers.
      So we need to return a /list/ of data constructors that are used.
      
      This entailed a bit of refactoring, as usual.
      
      Fixes Trac #12067
      23b80ac4
  18. 23 Jun, 2016 2 commits
  19. 20 Jun, 2016 1 commit
    • thomie's avatar
      Testsuite: mark tests expect broken · 1d938aa3
      thomie authored
      * CgStaticPointers, GcStaticPointers, ListStaticPointers,
        TcStaticPointers01, TcStaticPointers02:  #12207
      * T11535: #12210
      * ffi017/ffi021: #12209
      * T11108: #11108
      * T9646: #9646
      1d938aa3
  20. 13 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve typechecking of let-bindings · 15b9bf4b
      Simon Peyton Jones authored
      This major commit was initially triggered by #11339, but it spiraled
      into a major review of the way in which type signatures for bindings
      are handled, especially partial type signatures.  On the way I fixed a
      number of other bugs, namely
         #12069
         #12033
         #11700
         #11339
         #11670
      
      The main change is that I completely reorganised the way in which type
      signatures in bindings are handled. The new story is in TcSigs
      Note [Overview of type signatures].  Some specific:
      
      * Changes in the data types for signatures in TcRnTypes:
        TcIdSigInfo and new TcIdSigInst
      
      * New module TcSigs deals with typechecking type signatures
        and pragmas. It contains code mostly moved from TcBinds,
        which is already too big
      
      * HsTypes: I swapped the nesting of HsWildCardBndrs
        and HsImplicitBndsrs, so that the wildcards are on the
        oustide not the insidde in a LHsSigWcType.  This is just
        a matter of convenient, nothing deep.
      
      There are a host of other changes as knock-on effects, and
      it all took FAR longer than I anticipated :-).  But it is
      a significant improvement, I think.
      
      Lots of error messages changed slightly, some just variants but
      some modest improvements.
      
      New tests
      
      * typecheck/should_compile
          * SigTyVars: a scoped-tyvar test
          * ExPat, ExPatFail: existential pattern bindings
          * T12069
          * T11700
          * T11339
      
      * partial-sigs/should_compile
          * T12033
          * T11339a
          * T11670
      
      One thing to check:
      
      * Small change to output from ghc-api/landmines.
        Need to check with Alan Zimmerman
      15b9bf4b
  21. 09 Jun, 2016 1 commit
  22. 22 Apr, 2016 1 commit
  23. 20 Apr, 2016 1 commit
    • Simon Peyton Jones's avatar
      SCC analysis for instances as well as types/classes · 353d8ae6
      Simon Peyton Jones authored
      This big patch is in pursuit of Trac #11348.
      
      It is largely the work of Alex Veith (thank you!), with some
      follow-up simplification and refactoring from Simon PJ.
      
      The main payload is described in RnSource
        Note [Dependency analysis of type, class, and instance decls]
      which is pretty detailed.
      
      * There is a new data type HsDecls.TyClGroup, for a strongly
        connected component of type/class/instance/role decls.
      
        The hs_instds field of HsGroup disappears, in consequence
      
        This forces some knock-on changes, including a minor
        haddock submodule update
      
      Smaller, weakly-related things
      
      * I found that both the renamer and typechecker were building an
        identical env for RoleAnnots, so I put common code for
        RoleAnnotEnv in RnEnv.
      
      * I found that tcInstDecls1 had very clumsy error handling, so I
        put it together into TcInstDcls.doClsInstErrorChecks
      353d8ae6
  24. 15 Apr, 2016 1 commit
  25. 12 Apr, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11811. · b1084fd7
      eir@cis.upenn.edu authored
      Previously, I had forgotten to omit variables already in scope
      from the TypeInType CUSK check. Simple enough to fix.
      
      Test case: typecheck/should_compile/T11811
      b1084fd7
  26. 26 Mar, 2016 1 commit
  27. 17 Mar, 2016 1 commit
  28. 15 Mar, 2016 2 commits
  29. 26 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Exclude TyVars from the constraint solver · 7496be5c
      Simon Peyton Jones authored
      There is a general invariant that the constraint solver doesn't see
      TyVars, only TcTyVars.  But when checking the generic-default
      signature of a class, we called checkValidType on the generic-default
      type, which had the class TyVar free. That in turn meant that it wasn't
      considered during flattening, which led to the error reported in
      Trac #11608.
      
      The fix is simple: call checkValidType on the /closed/ type. Easy.
      
      While I was at it, I added a bunch of ASSERTs about the TcTyVar
      invariant.
      7496be5c
  30. 17 Feb, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Fix #11246. · 489e6ab5
      eir@cis.upenn.edu authored
      We have to instantiate any invisible arguments to type families
      right away. This is now done in tcTyCon in TcHsType.
      
      testcase: typecheck/should_compile/T11246
      489e6ab5
    • thomie's avatar
      Testsuite: delete compiler_lt/le/gt/ge setup functions · 6f25fb32
      thomie authored
      Since we're not consisently keeping track of which tests should pass
      with which compiler versions, there is no point in keeping these
      functions.
      
      Update submodules containers, hpc and stm.
      6f25fb32
  31. 12 Feb, 2016 1 commit
  32. 10 Feb, 2016 1 commit