1. 20 Mar, 2016 10 commits
  2. 19 Mar, 2016 1 commit
  3. 17 Mar, 2016 4 commits
    • eir@cis.upenn.edu's avatar
      Fix #11512 by getting visibility right for methods · f4f315a3
      eir@cis.upenn.edu authored
      Test case: typecheck/should_compile/T11512
    • eir@cis.upenn.edu's avatar
      Fix #11716. · 3fe87aa0
      eir@cis.upenn.edu authored
      There were several smallish bugs here:
       - We had too small an InScopeSet when rejigging GADT return types.
       - When adding the extra_tvs with a datatype kind signature, we
         were sometimes changing Uniques of an explicitly bound kind var.
       - Using coercionKind in the flattener got the wrong visibility
         for a binder. Now we just zonk to get what we need.
      Test case: dependent/should_compile/RaeJobTalk
    • Csongor Kiss's avatar
      typechecker: fix trac issue #11708 · c5ed41cb
      Csongor Kiss authored and eir@cis.upenn.edu's avatar eir@cis.upenn.edu committed
      Summary: Fixes T11708
      Reviewers: austin, bgamari, goldfire, simonpj
      Reviewed By: goldfire, simonpj
      Subscribers: simonpj, goldfire, thomie
      Differential Revision: https://phabricator.haskell.org/D2006
      GHC Trac Issues: #11708
    • eir@cis.upenn.edu's avatar
      Fix #11711. · b5565f1a
      eir@cis.upenn.edu authored
      There were two bugs here, both simple: we need to filter out
      covars before calling isMetaTyVar in the solver, and TcPat had
      a tcSubType the wrong way round.
      test case: dependent/should_compile/T11711
  4. 16 Mar, 2016 4 commits
    • Erik de Castro Lopo's avatar
      DriverPipeline: Fix 'unused arguments' warnings from Clang · 46f9a476
      Erik de Castro Lopo authored
      When using Clang as the C compiler, over 100 tests were failing
      due to Clang reporting that some command line arguments were not
      being used. These warnings only occur when Clang is compiling
      assembler files which happens in two places, one of which already
      conditionally adding `-Qunused-arguments` to the command line when
      the compiler was Clang. This fixes the other.
      Test Plan: validate with clang as the C compiler
      Reviewers: bgamari, hvr, austin, rwbarton
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1998
      GHC Trac Issues: #11684
    • eir@cis.upenn.edu's avatar
      Clean up some pretty-printing in errors. · 5d98b8bf
      eir@cis.upenn.edu authored
      It turns out that there were some pretty egregious mistakes
      in the code that suggested -fprint-explicit-kinds, which are
      fixed. This commit also reorders a bunch of error messages,
      which I think is an improvement.
      This also adds the test case for #11471, which is what
      triggered the cleanup in TcErrors. Now that #11473 is done,
      there is nothing more outstanding for #11471.
      test case: dependent/should_fail/T11471
    • eir@cis.upenn.edu's avatar
      Fix printing of "kind" vs. "type" · f602f4a6
      eir@cis.upenn.edu authored
      This is as reported in #11471, though it's not the focus of that
      test case: polykinds/KindVType
    • eir@cis.upenn.edu's avatar
      Fix #11473. · aade1112
      eir@cis.upenn.edu authored
      I've added a check in the zonker for representation polymorphism.
      I don't like having this be in the zonker, but I don't know where
      else to put it. It can't go in TcValidity, because a clever enough
      user could convince the solver to do bogus representation polymorphism
      even though there's nothing obviously wrong in what they wrote.
      Note that TcValidity doesn't run over *expressions*, which is where
      this problem arises.
      In any case, the check is simple and it works.
      test case: dependent/should_fail/T11473
  5. 15 Mar, 2016 14 commits
    • eir@cis.upenn.edu's avatar
      Fix #11357. · 1eefedf7
      eir@cis.upenn.edu authored
      We were looking at a data instance tycon for visibility info,
      which is the wrong place to look. Look at the data family tycon
      Also improved the pretty-printing near there to suppress kind
      arguments when appropriate.
    • eir@cis.upenn.edu's avatar
    • eir@cis.upenn.edu's avatar
      Remove redundant anonymiseTyBinders (#11648) · 19be5385
      eir@cis.upenn.edu authored
      This was necessary in an earlier version of the patch for #11648,
      but not in the final version. I forgot to remove it.
    • eir@cis.upenn.edu's avatar
    • eir@cis.upenn.edu's avatar
      Allow eager unification with type families. · 3f5d1a13
      eir@cis.upenn.edu authored
      Previously, checkTauTvUpdate, used in the eager unifier (TcUnify)
      right before writing to a metavar, refused to write a metavar to
      a type involving type functions. The reason for this was given
      in a Note, but the Note didn't make all that much sense and even
      admitted that it was a bit confused. The Note, in turn, referred
      to another Note, which it was quite sceptical of, as well.
      The type-family check was slowing down performance, so I tried
      removing it, running the tests referred to in the Note. The tests
      all passed without the check. Looking at more test results, I
      saw several error messages improve without the check, and some cases
      where GHC looped (T7788, in particular) it now doesn't.
      So, all in all, quite a win: Two hairy Notes removed, several lines
      of code removed, better performance, and improved output.
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Fix #11648. · 55577a91
      eir@cis.upenn.edu authored
      We now check that a CUSK is really a CUSK and issue an error if
      it isn't. This also involves more solving and zonking in
      kcHsTyVarBndrs, which was the outright bug reported in #11648.
      Test cases: polykinds/T11648{,b}
      This updates the haddock submodule.
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Document TypeInType (#11614) · e7a8cb14
      eir@cis.upenn.edu authored
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Test case for #11699 in typecheck/should_compile · 693b38cb
      eir@cis.upenn.edu authored
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Expand Note [Non-trivial definitional equality] · 6c768fcf
      eir@cis.upenn.edu authored
      This adapts the text from D1944.
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Refactor visible type application. · 972730cc
      eir@cis.upenn.edu authored
      This replaces the old HsType and HsTypeOut constructors
      with HsAppType and HsAppTypeOut, leading to some simplification.
      (This refactoring addresses #11329.)
      This also fixes #11456, which stumbled over HsType (which is
      not an expression).
      test case: ghci/scripts/T11456
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Fix #11401. · 35d37ff8
      eir@cis.upenn.edu authored
      This commit teaches shortCutReduction about Derived constraints.
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Fix #11334. · 84c773e1
      eir@cis.upenn.edu authored
      Now we fail when trying to default non-*-kinded kind variables
      with -XNoPolyKinds.
      test case: dependent/should_fail/T11334
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Fix #11407. · e9bf7bb5
      eir@cis.upenn.edu authored
      This removes the `defer_me` check that was in checkTauTvUpdate
      and uses only a type family check instead. The old defer_me check
      repeated work done by fast_check in occurCheckExpand.
      There is also some error message improvement, necessitated by
      the terrible error message that the test case produced, even when
      it didn't consume all of memory.
      test case: dependent/should_fail/T11407
      [skip ci]
    • eir@cis.upenn.edu's avatar
      Move and expand (slightly) TypeApplications docs · 18fbfa39
      eir@cis.upenn.edu authored
      [skip ci]
  6. 14 Mar, 2016 2 commits
  7. 13 Mar, 2016 1 commit
  8. 12 Mar, 2016 3 commits
    • Erik de Castro Lopo's avatar
      LlvmCodeGen: Fix generation of malformed LLVM blocks · 92821ec9
      Erik de Castro Lopo authored and Ben Gamari's avatar Ben Gamari committed
      Commit 673efccb uncovered a bug in LLVM code generation that produced
      LLVM code that the LLVM compiler refused to compile:
            br label %clpH
      This may well be a bug in LLVM itself. The solution is to keep the
      existing entry label and rewrite the function as:
            br label %nPV
            br label %nPV
      Thanks to Ben Gamari for pointing me in the right direction on this
      Test Plan: Build GHC with BuildFlavour=quick-llvm
      Reviewers: hvr, austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1996
      GHC Trac Issues: #11649
    • lukyanov's avatar
      ghci: add message when reusing compiled code #9887 · 41051dd8
      lukyanov authored and Ben Gamari's avatar Ben Gamari committed
      Reviewers: austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1991
      GHC Trac Issues: #9887
    • Ben Gamari's avatar
      Simplify: Make generated names more useful · 4d791b4f
      Ben Gamari authored and Ben Gamari's avatar Ben Gamari committed
      makeTrivial is responsible for concocting names during simplification.
      Previously, however, it would make no attempt to generate a name that
      might be useful to later readers of the resulting Core. Here we add a
      bit of state to SimplEnv: a finite depth stack of binders within which
      we are currently simplifying. We then derive generated binders from this
      See #11676.
      Open questions:
        * Is there a better way to accomplish this?
        * Is `maxContextDepth` too large/small?
      Test Plan: Validate, look at Core.
      Reviewers: austin, simonpj
      Reviewed By: simonpj
      Subscribers: thomie, simonpj
      Differential Revision: https://phabricator.haskell.org/D1970
      GHC Trac Issues: #11676
  9. 11 Mar, 2016 1 commit
    • Sergei Trofimovich's avatar
      rts: fix threadStackUnderflow type in cmm · e46742f5
      Sergei Trofimovich authored
      stg_stack_underflow_frame had an incorrect
      call of C function 'threadStackUnderflow':
          ("ptr" ret_off) =
            foreign "C" threadStackUnderflow(
      Which means it's prototype is:
          void * (*) (W_, void*);
      While real prototype is:
          W_ (*) (Capability *cap, StgTSO *tso);
      The fix is simple. Fix type annotations:
          (ret_off) =
            foreign "C" threadStackUnderflow(
              MyCapability() "ptr",
              CurrentTSO "ptr");
      Noticed when debugged T9045 test failure
      on m68k target which distincts between
      pointer and non pointer return types
      (uses different registers)
      While at it noticed and fixed return types
      for 'throwTo' and 'findSpark'.
      Trac #11395
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>