1. 29 Jul, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #14045 by omitting an unnecessary check · d1ef223c
      Richard Eisenberg authored
      Previously, we checked the number of patterns in a data instances
      for all data families whose kind did not end in a kind variable.
      But, of course, undersaturating instances can happen even without
      the kind ending in a kind variable. So I've omitted the arity check.
      Data families aren't as particular about their arity as type families
      are (because data families can be undersaturated). Still, this change
      degrades error messages when instances don't have the right arity;
      now, instead of reporting a simple mismatch in the number of patterns,
      GHC reports kind errors. The new errors are fully accurate, but perhaps
      not as easy to work with. Still, with the new flexibility of allowing
      data family instances with varying numbers of patterns, I don't see
      a better way.
      
      This commit also improves source fidelity in some error messages,
      requiring more changes than really are necessary. But without these
      changes, error messages around mismatched associated instance heads
      were poor.
      
      test cases: indexed-types/should_compile/T14045,
                  indexed-types/should_fail/T14045a
      d1ef223c
  2. 28 Jul, 2017 3 commits
    • 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
      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
  3. 27 Jul, 2017 6 commits
    • 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
      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
      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
  4. 26 Jul, 2017 3 commits
    • Gabor Greif's avatar
      Fix note references and some typos · 362339dd
      Gabor Greif authored
      362339dd
    • 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
  5. 25 Jul, 2017 2 commits
  6. 20 Jul, 2017 3 commits
  7. 19 Jul, 2017 2 commits
    • Ryan Scott's avatar
      Fix #13983 by creating a TyConFlavour type, and using it · 6e3c901d
      Ryan Scott authored
      An error message was referring to a type synonym as a datatype.
      Annoyingly, learning that the TyCon over which the error message is
      operating is actually a type synonym was previously impossible, since
      that code only had access to a TcTyCon, which doesn't retain any
      information about what sort of TyCon it is.
      
      To rectify this, I created a new TyConFlavour datatype, intended to
      capture roughly what sort of TyCon we're dealing with. I then performing
      the necessary plumbing to ensure all TcTyCons have a TyConFlavour, and
      propagated this information through to the relevant error message.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13983
      
      Differential Revision: https://phabricator.haskell.org/D3747
      6e3c901d
    • Ryan Scott's avatar
      Allow visible type application for [] · c9e4c861
      Ryan Scott authored
      This amounts to a one-line change in `tcExpr`. I've added a Note to
      explain what is going on.
      
      This requires a separate change in the pattern-match checker to
      account for the fact that typechecked `[]` expressions become
      `ConLikeOut`s, not `ExplicitList`s.
      
      Test Plan: make test TEST=T13680
      
      Reviewers: goldfire, mpickering, austin, bgamari
      
      Reviewed By: mpickering, bgamari
      
      Subscribers: rwbarton, thomie, goldfire
      
      GHC Trac Issues: #13680
      
      Differential Revision: https://phabricator.haskell.org/D3733
      c9e4c861
  8. 12 Jul, 2017 1 commit
  9. 11 Jul, 2017 4 commits
    • Ömer Sinan Ağacan's avatar
      Mention which -Werror promoted a warning to an error · 4befb415
      Ömer Sinan Ağacan authored
      Previously -Werror or -Werror=flag printed warnings as usual and then
      printed
      these two lines:
      
          <no location info>: error:
          Failing due to -Werror.
      
      This is not ideal: first, it's not clear which flag made one of the
      warnings an
      error. Second, warning messages are not modified in any way, so there's
      no way
      to know which warnings caused this error.
      
      With this patch we (1) promote warning messages to error messages if a
      relevant
      -Werror is enabled (2) mention which -Werror is used during this
      promotion.
      
      Previously:
      
          [1 of 1] Compiling Main             ( test.hs, test.o )
      
          test.hs:9:10: warning: [-Wincomplete-patterns]
              Pattern match(es) are non-exhaustive
              In a case alternative: Patterns not matched: (C2 _)
            |
          9 | sInt s = case s of
            |          ^^^^^^^^^...
      
          test.hs:12:14: warning: [-Wmissing-fields]
              • Fields of ‘Rec’ not initialised: f2
              • In the first argument of ‘print’, namely ‘Rec {f1 =
      1}’
                In the expression: print Rec {f1 = 1}
                In an equation for ‘main’: main = print Rec {f1 = 1}
             |
          12 | main = print Rec{ f1 = 1 }
             |              ^^^^^^^^^^^^^
      
          <no location info>: error:
          Failing due to -Werror.
      
      Now:
      
          [1 of 1] Compiling Main             ( test.hs, test.o )
      
          test.hs:9:10: error: [-Wincomplete-patterns,
      -Werror=incomplete-patterns]
              Pattern match(es) are non-exhaustive
              In a case alternative: Patterns not matched: (C2 _)
            |
          9 | sInt s = case s of
            |          ^^^^^^^^^...
      
          test.hs:12:14: error: [-Wmissing-fields, -Werror=missing-fields]
              • Fields of ‘Rec’ not initialised: f2
              • In the first argument of ‘print’, namely ‘Rec {f1 =
      1}’
                In the expression: print Rec {f1 = 1}
                In an equation for ‘main’: main = print Rec {f1 = 1}
             |
          12 | main = print Rec{ f1 = 1 }
             |              ^^^^^^^^^^^^^
      
      Test Plan: - Update old tests, add new tests if there aren't any
      relevant tests
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3709
      4befb415
    • Ryan Scott's avatar
      Remove unnecessarily returned res_ty from rejigConRes · a249e939
      Ryan Scott authored
      @goldfire noticed that we don't need to thread through `res_ty`
      through to the return type of `rejigConRes`, as it never changes.
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D3725
      a249e939
    • Ryan Scott's avatar
      Suppress unused warnings for selectors for some derived classes · 15fcd9ad
      Ryan Scott authored
      Although derived `Read`, `Show`, and `Generic` instances technically
      don't //use// the record selectors of the data type for which an
      instance is being derived, the derived code is affected by the
      //presence// of record selectors. As a result, we should suppress
      `-Wunused-binds` for those record selectors when deriving these classes.
      This is accomplished by threading through more information from
      `hasStockDeriving`.
      
      Test Plan: make test TEST=T13919
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13919
      
      Differential Revision: https://phabricator.haskell.org/D3704
      15fcd9ad
    • patrickdoc's avatar
      Make ':info Coercible' display an arbitrary string (fixes #12390) · 905dc8bc
      patrickdoc authored
      This change enables the addition of an arbitrary string to the output of
      GHCi's ':info'. It was made for Coercible in particular but could be
      extended if desired.
      
      Updates haddock submodule.
      
      Test Plan: Modified test 'ghci059' to match new output.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #12390
      
      Differential Revision: https://phabricator.haskell.org/D3634
      905dc8bc
  10. 06 Jul, 2017 1 commit
  11. 03 Jul, 2017 2 commits
  12. 29 Jun, 2017 2 commits
  13. 28 Jun, 2017 6 commits
  14. 27 Jun, 2017 2 commits
  15. 23 Jun, 2017 1 commit
    • Matthew Pickering's avatar
      Use actual universal tvs in check for naughty record selectors · 90771209
      Matthew Pickering authored
      The naughty record selector check means to limit selectors which would
      lead to existential tyvars escaping their scope. With record pattern
      synonyms, there are situations where universal tyvars don't appear in
      the result type, for example:
      
      ```
      pattern ReadP :: Read a => a -> String
      pattern ReadP{readp} <- (read -> readp)
      ```
      
      This is a similar issue to #11224 where we assumed that we can decide
      which variables are universal and which are existential by the syntactic
      check of seeing which appear in the result type. The fix is to use
      `univ_tvs` from `conLikeFullSig` rather than the previous approximation.
      But we must also remember to apply `EqSpec`s so we use the free
      variables from `inst_tys` which is precisely `univ_tvs` with `EqSpecs`
      applied.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3649
      90771209
  16. 20 Jun, 2017 1 commit