1. 26 Apr, 2016 13 commits
  2. 24 Apr, 2016 1 commit
  3. 22 Apr, 2016 14 commits
    • niteria's avatar
      Get rid of varSetElemsWellScoped in abstractFloats · 03006f5e
      niteria authored
      It's possible to get rid of this use site in a local way
      and it introduces unneccessary nondeterminism.
      Test Plan: ./validate
      Reviewers: simonmar, goldfire, austin, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2122
      GHC Trac Issues: #4012
    • niteria's avatar
      Make benign non-determinism in pretty-printing more obvious · 0f96686b
      niteria authored
      This change takes us one step closer to being able to remove
      `varSetElemsWellScoped`. The end goal is to make every source
      of non-determinism obvious at the source level, so that when
      we achieve determinism it doesn't get broken accidentally.
      Test Plan: compile GHC
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      Reviewed By: simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2123
      GHC Trac Issues: #4012
    • niteria's avatar
      Remove unused tyCoVarsOfTelescope · a9076fc2
      niteria authored
      Grepping reveals that it's not used. I suspect that it isn't useful
      Test Plan: grep
      Reviewers: goldfire, austin, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: thomie, simonmar
      Differential Revision: https://phabricator.haskell.org/D2134
    • niteria's avatar
      Typo: veraibles -> variables · 4221cc28
      niteria authored
    • niteria's avatar
      Fix typos: alpah -> alpha · ed4a2289
      niteria authored
    • Simon Peyton Jones's avatar
      Refactor free tyvars on LHS of rules · 6ad2b42f
      Simon Peyton Jones authored
      A RULE can have unbound meta-tyvars on the LHS.  Consider
        data T a = C
        foo :: T a -> Int
        foo C = 1
        {-# RULES "myrule"  foo C = 1 #-}
      After type checking the LHS becomes (foo alpha (C alpah)) and we do
      not want to zap the unbound meta-tyvar 'alpha' to Any, because that
      limits the applicability of the rule.  Instead, we want to quantify
      over it!
      Previously there was a rather clunky implementation of this
      quantification, buried in the zonker in TcHsSyn (zonkTvCollecting).
      This patch refactors it so that the zonker just turns the meta-tyvar
      into a skolem, and the desugarer adds the quantification.  See DsBinds
      Note [Free tyvars on rule LHS]. As it happened, the desugarer was
      already doing something similar for dictionaries. See DsBinds
      Note [Free dictionaries on rule LHS]
      No change in functionality, but less cruft.
    • Simon Peyton Jones's avatar
      Simplify defaultKindVar and friends · 970ff585
      Simon Peyton Jones authored
      I found zonkQuantifiedTyVar rather complicated, especially the two
      places where we defaulted RuntimeRep variables. This simplifies and
      modularises the story.
      Refactoring only.
    • Simon Peyton Jones's avatar
      Avoid double error on out-of-scope identifier · c2b7a3d9
      Simon Peyton Jones authored
      Trac #11941 demonstrated a case where an out-of-scope error also
      gave rise to a (bogus and confusing) stage restriction message.
      It's caused by the fact that out-of-scope errors do not stop
      renaming, but rather return an "unbound name".  We need to
      detect this in the stage-restriction test to avoid the double
      error.  Easy fix.
    • Simon Peyton Jones's avatar
      A little more debug tracing · 24d3276d
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      wibble to simplifiable · 26a18041
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Test Trac #3990 · 251a376b
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Warn about simplifiable class constraints · 9421b0c7
      Simon Peyton Jones authored
      Provoked by Trac #11948, this patch adds a new warning to GHC
      It warns if you write a class constraint in a type signature that
      can be simplified by an existing instance declaration.  Almost always
      this means you should simplify it right now; type inference is very
      fragile without it, as #11948 shows.
      I've put the warning as on-by-default, but I suppose that if there are
      howls of protest we can move it out (as happened for -Wredundant-constraints.
      It actually found an example of an over-complicated context in CmmNode.
      Quite a few tests use these weird contexts to trigger something else,
      so I had to suppress the warning in those.
      The 'haskeline' library has a few occurrences of the warning (which
      I think should be fixed), so I switched it off for that library in
      The warning itself is done in TcValidity.check_class_pred.
      HOWEVER, when type inference fails we get a type error; and the error
      suppresses the (informative) warning.  So as things stand, the warning
      only happens when it doesn't cause a problem.  Not sure what to do
      about this, but this patch takes us forward, I think.
    • Simon Peyton Jones's avatar
      Do not use defaulting in ambiguity check · edf54d72
      Simon Peyton Jones authored
      This fixes Trac #11947.  See TcSimplify
      Note [No defaulting in the ambiguity check]
    • Simon Peyton Jones's avatar
      Improve the behaviour of warnIf · f02af79e
      Simon Peyton Jones authored
      Now that warnIf takes a "reason", we can test the reason
      in warnIf rather than in the caller.  Less code, and less
      risk of getting the test and the reason out of sync.
  4. 21 Apr, 2016 2 commits
  5. 20 Apr, 2016 10 commits
    • niteria's avatar
      Point to note about FV eta-expansion performance · 98a14ff0
      niteria authored
    • niteria's avatar
      Rename FV related functions · 2e33320a
      niteria authored
      This is from Simon's suggestion:
      * `tyCoVarsOfTypesAcc` is a terrible name for a function with a
        perfectly decent type `[Type] -> FV`. Maybe `tyCoFVsOfTypes`?
        Similarly others
      * `runFVList` is also terrible, but also has a decent type.
        Maybe just `fvVarList` (and `fvVarSet` for `runFVSet`).
      * `someVars` could be `mkFVs :: [Var] -> FV`.
    • Simon Peyton Jones's avatar
      Accept tcrun045 output · 55b1b85d
      Simon Peyton Jones authored
      My validate didn't catch this one; it is fallout
      (actually an improvement) from
        353d8a SCC analysis for instances as well as types/classes
    • niteria's avatar
      Build a correct substitution in dataConInstPat · 62943d2a
      niteria authored
      This adds the tyvars of the domain of the substitution into the in-scope
      set as well.
      What I'm not sure here is if the kinds can have any free vars that
      should be in the in-scope set as well.
      Test Plan: ./validate
      Reviewers: goldfire, austin, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: thomie, simonmar
      Differential Revision: https://phabricator.haskell.org/D2094
      GHC Trac Issues: #11371
    • niteria's avatar
      Kill unnecessary varSetElemsWellScoped in deriveTyData · 687c7780
      niteria authored
      varSetElemsWellScoped introduces unnecessary non-determinism and it's possible
      to do the same thing deterministically for the same price.
      Test Plan: ./validate
      Reviewers: austin, simonmar, bgamari, simonpj
      Reviewed By: simonpj
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D2124
      GHC Trac Issues: #4012
    • Simon Peyton Jones's avatar
      Tighten up imports on TcTyClsDecls · cdcf014d
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Fix two buglets in 17eb2419 noticed by Richard · 61191dee
      Simon Peyton Jones authored
      These are corner cases in
         17eb2419 Refactor computing dependent type vars
      and I couldn't even come up with a test case
      * In TcSimplify.simplifyInfer, in the promotion step, be sure
        to promote kind variables as well as type variables.
      * In TcType.spiltDepVarsOfTypes, the CoercionTy case, be sure
        to get the free coercion variables too.
    • 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
    • Simon Peyton Jones's avatar
      Tighten up imports, white space · 7319b80a
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Define NameSet.intersectFVs · 871f684d
      Simon Peyton Jones authored
      I want it for subsequent commits