1. 28 Jul, 2017 12 commits
    • Moritz Angermann's avatar
      Add “BINARY_DIST_DIR” to Makefile · 274e9b27
      Moritz Angermann authored
      This allows to customize the location where binary distributions are
      placed with `make binary-dist`.
      
      E.g. using:
      ```
      BINARY_DIST_DIR=/path/to/bindists make binary-dist
      ```
      will place binary dists outside of the source tree into the given
      folder.
      
      This change falls back to ".", which is the old behaviour.
      
      Test Plan: build binary-dist
      
      Reviewers: bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3798
      274e9b27
    • Ben Gamari's avatar
      testsuite: Add test for #14028 · 262bb95f
      Ben Gamari authored
      Reviewers: austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14028
      
      Differential Revision: https://phabricator.haskell.org/D3788
      262bb95f
    • Ben Gamari's avatar
      testsuite: Produce JUnit output · 54d3a1fd
      Ben Gamari authored
      Test Plan: Validate, try ingesting into Jenkins.
      
      Reviewers: austin
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13716
      
      Differential Revision: https://phabricator.haskell.org/D3796
      54d3a1fd
    • Jared Weakly's avatar
      Switched out optparse for argparse in runtests.py · 5e940bd3
      Jared Weakly authored
      Tangentially related to my prior work on trac ticket #12758.
      Signed-off-by: default avatarJared Weakly <jweakly@pdx.edu>
      
      Reviewers: austin, bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3792
      5e940bd3
    • Ryan Scott's avatar
      Add regression tests for #13601, #13780, #13877 · 424ecadb
      Ryan Scott authored
      Summary:
      Some recent commits happened to fix other issues:
      
      * c2417b87 fixed #13601 and #13780
      * 8e15e3d3 fixed the original program in #13877
      
      Let's add regression tests for each of these to ensure they stay fixed.
      
      Test Plan: make test TEST="T13601 T13780a T13780c T13877"
      
      Reviewers: goldfire, bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13601, #13780, #13877
      
      Differential Revision: https://phabricator.haskell.org/D3794
      424ecadb
    • Ryan Scott's avatar
      Merge types and kinds in DsMeta · b3b564fb
      Ryan Scott authored
      Summary:
      Types and kinds are now the same in GHC... well, except in the code
      that involves Template Haskell, where types and kinds are given separate
      treatment. This aims to unify that treatment in the `DsMeta` module.
      
      The gist of this patch is replacing all uses of `repLKind` with `repLTy`.
      This is isn't quite as simple as one might imagine, since `repLTy` returns a
      `Core (Q Type)` (a monadic expression), whereas `repLKind` returns a
      `Core Kind` (a pure expression). This causes many awkward impedance mismatches.
      
      One option would be to change every combinator in `Language.Haskell.TH.Lib` to
      take `KindQ` as an argument instead of `Kind`. But this would be a breaking
      change of colossal proportions.
      
      Instead, this patch takes a somewhat different approach. This migrates the
      existing `Language.Haskell.TH.Lib` module to
      `Language.Haskell.TH.Lib.Internal`, and changes all `Kind`-related combinators
      in `Language.Haskell.TH.Lib.Internal` to live in `Q`. The new
      `Language.Haskell.TH.Lib` module then re-exports most of
      `Language.Haskell.TH.Lib.Internal` with the exception of the `Kind`-related
      combinators, for which it redefines them to be their current definitions (which
      don't live in `Q`). This allows us to retain backwards compatibility with
      previous `template-haskell` releases, but more importantly, it allows GHC to
      make as many changes to the `Internal` code as it wants for its purposes
      without fear of disrupting the public API.
      
      This solves half of #11785 (the other half being `TcSplice`).
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #11785
      
      Differential Revision: https://phabricator.haskell.org/D3751
      b3b564fb
    • Ryan Scott's avatar
      Error eagerly after renaming failures in reifyInstances · d6186496
      Ryan Scott authored
      Summary:
      Previously, if `reifyInstances` failed to discover a `Name` during
      renaming, it would blindy charge into typechecking, at which point GHC would
      become very confused at the absence of that `Name` and throw an internal error.
      A simple workaround is to fail eagerly after renaming errors.
      
      Test Plan: make test TEST=T13837
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13837
      
      Differential Revision: https://phabricator.haskell.org/D3793
      d6186496
    • Simon Peyton Jones's avatar
      Add DebugCallStack to piResultTy · ad0037ea
      Simon Peyton Jones authored
      This was provoked by an ASSERT failure when debugging #14038,
      but it's a godo idea anyway.
      ad0037ea
    • Simon Peyton Jones's avatar
      Do not discard insolubles in implications · 452755de
      Simon Peyton Jones authored
      Trac #14000 showed up two errors
      
      * In TcRnTypes.dropInsolubles we dropped all implications, which
        might contain the very insolubles we wanted to keep.  This was
        an outright error, and is why the out-of-scope error was actually
        lost altogether in Trac #14000
      
      * In TcSimplify.simplifyInfer, if there are definite (insoluble)
        errors, it's better to suppress the following ambiguity test,
        because the type may be bogus anyway.  See TcSimplify
        Note [Quantification with errors].  This fix seems a bit clunky,
        but it'll do for now.
      452755de
    • Simon Peyton Jones's avatar
      Fix ASSERT failure in tc269 · b1317a35
      Simon Peyton Jones authored
      This ASSERT failure (in substTy) was reported in Trac #14024.
      
      This patch gets the in-scope set right.
      
      (Does not fix tests T13822 or T13594.)
      b1317a35
    • Simon Peyton Jones's avatar
      af6d225f
    • Simon Peyton Jones's avatar
      Fix instantiation of pattern synonyms · 6b77914c
      Simon Peyton Jones authored
      In Check.hs (pattern match ovelap checking) we to figure out the
      instantiation of a pattern synonym from the type of the pattern. We
      were doing this utterly wrongly.  Trac #13768 demonstrated this
      bogosity.
      
      The fix is easy; and is described in PatSyn.hs
        Note [Pattern synonym result type]
      6b77914c
  2. 27 Jul, 2017 15 commits
    • Andreas Klebinger's avatar
      Initialize hs_init with UTF8 encoded arguments on Windows. · 7af0b906
      Andreas Klebinger authored
      Summary:
      Get utf8 encoded arguments before we call hs_init and use them
      instead of ignoring hs_init arguments. This reduces differing
      behaviour of the RTS between windows and linux and simplifies
      the code involved.
      
      A few testcases were changed to expect the same result on windows
      as on linux after the changes.
      
      This fixes #13940.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar, Phyx
      
      Subscribers: Phyx, rwbarton, thomie
      
      GHC Trac Issues: #13940
      
      Differential Revision: https://phabricator.haskell.org/D3739
      7af0b906
    • Richard Eisenberg's avatar
      Refactor tcInferApps. · 791947db
      Richard Eisenberg authored
      With the changes caused by the fix to #12369, it is now clearer
      how to rewrite tcInferApps and friends. This should change no
      behavior, but it does clean up a nasty corner of the type checker.
      This commit also removes some uses of substTyUnchecked.
      791947db
    • Richard Eisenberg's avatar
      Fix #12369 by being more flexible with data insts · 42392383
      Richard Eisenberg authored
      Previously, a data family's kind had to end in `Type`,
      and data instances had to list all the type patterns for the
      family. However, both of these restrictions were unnecessary:
      
      - A data family's kind can usefully end in a kind variable `k`.
        See examples on #12369.
      
      - A data instance need not list all patterns, much like how a
        GADT-style data declaration need not list all type parameters,
        when a kind signature is in place. This is useful, for example,
        here:
      
          data family Sing (a :: k)
          data instance Sing :: Bool -> Type where ...
      
      This patch also improved a few error messages, as some error
      plumbing had to be moved around.
      
      See new Note [Arity of data families] in FamInstEnv for more
      info.
      
      test case: indexed-types/should_compile/T12369
      42392383
    • Richard Eisenberg's avatar
      Fix #12176 by being a bit more careful instantiating. · 1696dbf4
      Richard Eisenberg authored
      Previously, looking up a TyCon that said "no" to mightBeUnsaturated
      would then instantiate all of its invisible binders. But this is
      wrong for vanilla type synonyms, whose RHS kind might legitimately
      start with invisible binders. So a little more care is taken now,
      only to instantiate those invisible binders that need to be (so that
      the TyCon isn't unsaturated).
      1696dbf4
    • Richard Eisenberg's avatar
      Document that type holes kill polymorphic recursion · ca471860
      Richard Eisenberg authored
      This "fixes" #11995.
      ca471860
    • Richard Eisenberg's avatar
      Fix #11963 by checking for more mixed type/kinds · 10d13b62
      Richard Eisenberg authored
      This is a straightforward fix -- there were just some omitted
      checks.
      
      test case: typecheck/should_fail/T11963
      10d13b62
    • Richard Eisenberg's avatar
      Track visibility in TypeEqOrigin · fb752133
      Richard Eisenberg authored
      A type equality error can arise from a mismatch between
      *invisible* arguments just as easily as from visible arguments.
      But we should really prefer printing out errors from visible
      arguments over invisible ones. Suppose we have a mismatch between
      `Proxy Int` and `Proxy Maybe`. Would you rather get an error
      between `Int` and `Maybe`? Or between `*` and `* -> *`? I thought
      so, too.
      
      There is a fair amount of plumbing with this one, but I think
      it's worth it.
      
      This commit introduces a performance regression in test
      perf/compiler/T5631. The cause of the regression is not the
      new visibility stuff, directly: it's due to a change from
      zipWithM to zipWith3M in TcUnify. To my surprise, zipWithM
      is nicely optimized (it fuses away), but zipWith3M is not.
      There are other examples of functions that could be made faster,
      so I've posted a separate ticket, #14037, to track these
      improvements. For now, I've accepted the small (6.6%) regression.
      fb752133
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
    • Richard Eisenberg's avatar
      Remove old coercion pretty-printer · 79cfb199
      Richard Eisenberg authored
      Now, all coercions are printed from IfaceType, just like types.
      
      This also changes the rendering of TransCo to use ; instead of
      a prefix operator.
      79cfb199
    • Richard Eisenberg's avatar
      Preserve CoVar uniques during pretty printing · bb2a446a
      Richard Eisenberg authored
      Previously, we did this for Types, but not for Coercions.
      bb2a446a
    • Richard Eisenberg's avatar
      Don't tidy vars when dumping a type · ef39af72
      Richard Eisenberg authored
      This makes variables print more consistenty in, say,
      -ddump-tc-trace.
      ef39af72
    • Richard Eisenberg's avatar
      Test #11672 in typecheck/should_fail/T11672. · 9a549756
      Richard Eisenberg authored
      I believe this was fixed with the fix for #11198.
      9a549756
    • Richard Eisenberg's avatar
      Fix #11400, #11560 by documenting an infelicity. · c9667d32
      Richard Eisenberg authored
      Really, the fix for both of these is #11307.
      c9667d32
    • Richard Eisenberg's avatar
      Improve error messages around kind mismatches. · 8e15e3d3
      Richard Eisenberg authored
      Previously, when canonicalizing (or unifying, in uType) a
      heterogeneous equality, we emitted a kind equality and used the
      resulting coercion to cast one side of the heterogeneous equality.
      
      While sound, this led to terrible error messages. (See the bugs
      listed below.) The problem is that using the coercion built from
      the emitted kind equality is a bit like a wanted rewriting a wanted.
      The solution is to keep heterogeneous equalities as irreducible.
      
      See Note [Equalities with incompatible kinds] in TcCanonical.
      
      This commit also removes a highly suspicious switch to FM_SubstOnly
      when flattening in the kinds of a type variable. I have no idea
      why this was there, other than as a holdover from pre-TypeInType.
      I've not left a Note because there is simply no reason I can conceive
      of that the FM_SubstOnly should be there.
      
      One challenge with this patch is that the emitted derived equalities
      might get emitted several times: when a heterogeneous equality is
      in an implication and then gets floated out from the implication,
      the Derived is present both in and out of the implication. This
      causes a duplicate error message. (Test case:
      typecheck/should_fail/T7368) Solution: track the provenance of
      Derived constraints and refuse to float out a constraint that has
      an insoluble Derived.
      
      Lastly, this labels one test (dependent/should_fail/RAE_T32a)
      as expect_broken, because the problem is really #12919. The
      different handling of constraints in this patch exposes the error.
      
      This fixes bugs #11198, #12373, #13530, and #13610.
      
      test cases:
      typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}
      8e15e3d3
    • Gabor Greif's avatar
      Remove unneeded import · 4a264157
      Gabor Greif authored
      4a264157
  3. 26 Jul, 2017 7 commits
    • Ryan Scott's avatar
      Fix #13968 by consulting isBuiltInOcc_maybe · d774b4e2
      Ryan Scott authored
      Summary:
      We were unconditionally reporting `Illegal binding of built-in syntax`
      in an error message, but this error doesn't make sense in certain Template
      Haskell scenarios which can trigger it. Let's give a more sensible error
      message by first checking if the name we're binding really is built-in syntax,
      using the handy `isBuiltInOcc_maybe` function.
      
      Test Plan: make test TEST=T13968
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13968
      
      Differential Revision: https://phabricator.haskell.org/D3789
      d774b4e2
    • Gabor Greif's avatar
      Fix note references and some typos · 362339dd
      Gabor Greif authored
      362339dd
    • Simon Peyton Jones's avatar
      Test Trac #14033 · d31181b9
      Simon Peyton Jones authored
      d31181b9
    • Simon Peyton Jones's avatar
      Comments only · f959624f
      Simon Peyton Jones authored
      f959624f
    • Simon Peyton Jones's avatar
      Comments and tc-tracing only · 6386fc32
      Simon Peyton Jones authored
      6386fc32
    • Simon Peyton Jones's avatar
      Fix binder visiblity for default methods · 75bf11c0
      Simon Peyton Jones authored
      Trac #13998 showed that default methods were getting bogus tyvar
      binder visiblity info; and that it matters in the code genreated
      by the default-method fill-in mechanism
      
      * The actual fix: in TcTyDecls.mkDefaultMethodType, make TyVarBinders
        with the right visibility info by getting TyConBinders from the
        class TyCon.  (Previously we made up visiblity info, but that
        caused #13998.)
      
      * Define TyCon.tyConTyVarBinders :: [TyConBinder] -> [TyVarBinder]
        which can build correct forall binders for
          a) default methods (Trac #13998)
          b) data constructors
        This was originally BuildTyCl.mkDataConUnivTyVarBinders
      
      * Move mkTyVarBinder, mkTyVarBinders from Type to Var
      75bf11c0
    • Simon Peyton Jones's avatar
      746ab0b4
  4. 25 Jul, 2017 6 commits