1. 21 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      
      ```haskell
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      ```
      
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      
      Fixes #11514.
      8d18a873
  2. 20 Mar, 2019 3 commits
  3. 15 Mar, 2019 2 commits
    • Ryan Scott's avatar
      Update Trac ticket URLs to point to GitLab · 610ec224
      Ryan Scott authored
      This moves all URL references to Trac tickets to their corresponding
      GitLab counterparts.
      610ec224
    • Ryan Scott's avatar
      Remove the GHCi debugger's panicking isUnliftedType check · 8162eab2
      Ryan Scott authored
      The GHCi debugger has never been that robust in the face of
      higher-rank types, or even types that are _interally_ higher-rank,
      such as the types of many class methods (e.g., `fmap`). In GHC 8.2,
      however, things became even worse, as the debugger would start to
      _panic_ when a user tries passing the name of a higher-rank thing
      to `:print`. This all ties back to a strange `isUnliftedType` check
      in `Debugger` that was mysteriously added 11 years ago
      (in commit 4d71f5ee) with no
      explanation whatsoever.
      
      After some experimentation, no one is quite sure what this
      `isUnliftedType` check is actually accomplishing. The test suite
      still passes if it's removed, and I am unable to observe any
      differences in debugger before even with data types that _do_ have
      fields of unlifted types (e.g., `data T = MkT Int#`). Given that
      this is actively causing problems (see #14828), the prudent thing
      to do seems to be just removing this `isUnliftedType` check, and
      waiting to see if anyone shouts about it. This patch accomplishes
      just that.
      
      Note that this patch fix the underlying issues behind #14828, as the
      debugger will still print unhelpful info if you try this:
      
      ```
      λ> f :: (forall a. a -> a) -> b -> b; f g x = g x
      λ> :print f
      f = (_t1::t1)
      ```
      
      But fixing this will require much more work, so let's start with the
      simple stuff for now.
      8162eab2
  4. 11 Mar, 2019 1 commit
    • Alec Theriault's avatar
      Ignore more version numbers in the testsuite · bcb6769c
      Alec Theriault authored
      Prevents some tests from failing just due to mismatched version numbers.
      
      These version numbers shouldn't cause tests to fail, especially since
      we *expect* them to be regularly incremented. The motivation for this
      particular set of changes came from the changes that came along with
      the `base` version bump in 8f19ecc9.
      bcb6769c
  5. 08 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Use captureTopConstraints in TcRnDriver calls · 5be7ad78
      Simon Peyton Jones authored
      Trac #16376 showed the danger of failing to report an error
      that exists only in the unsolved constraints, if an exception
      is raised (via failM).
      
      Well, the commit 5c1f268e (Fail fast in solveLocalEqualities)
      did just that -- i.e. it found errors in the constraints, and
      called failM to avoid a misleading cascade.
      
      So we need to be sure to call captureTopConstraints to report
      those insolubles.  This was wrong in TcRnDriver.tcRnExpr and
      in TcRnDriver.tcRnType.
      
      As a result the error messages from test T13466 improved slightly,
      a happy outcome.
      5be7ad78
  6. 07 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16391 by using occCheckExpand in TcValidity · 068b7e98
      Ryan Scott authored
      The type-variables-escaping-their-scope-via-kinds check in
      `TcValidity` was failing to properly expand type synonyms, which led
      to #16391. This is easily fixed by using `occCheckExpand` before
      performing the validity check.
      
      Along the way, I refactored this check out into its own function,
      and sprinkled references to Notes to better explain all of the moving
      parts. Many thanks to @simonpj for the suggestions.
      
      Bumps the haddock submodule.
      068b7e98
  7. 27 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Treat kind/type variables identically, demolish FKTV · 5bc195b1
      Vladislav Zavialov authored
      Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
      Fixes Trac #16334, Trac #16315
      
      With this patch, scoping rules for type and kind variables have been
      unified: kind variables no longer receieve special treatment. This
      simplifies both the language and the implementation.
      
      User-facing changes
      -------------------
      
      * Kind variables are no longer implicitly quantified when an explicit
        forall is used:
      
          p ::             Proxy (a :: k)    -- still accepted
          p :: forall k a. Proxy (a :: k)    -- still accepted
          p :: forall   a. Proxy (a :: k)    -- no longer accepted
      
        In other words, now we adhere to the "forall-or-nothing" rule more
        strictly.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * The -Wimplicit-kind-vars warning has been deprecated.
      
      * Kind variables are no longer implicitly quantified in constructor
        declarations:
      
          data T a        = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- no longer accepted
          data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- still accepted
      
        Related function: RnTypes.extractRdrKindSigVars
      
      * Implicitly quantified kind variables are no longer put in front of
        other variables:
      
          f :: Proxy (a :: k) -> Proxy (b :: j)
      
          f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b   -- old order
          f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b   -- new order
      
        This is a breaking change for users of TypeApplications. Note that
        we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
        See "Ordering of specified variables" in the User's Guide.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * In type synonyms and type family equations, free variables on the RHS
        are no longer implicitly quantified unless used in an outermost kind
        annotation:
      
          type T = Just (Nothing :: Maybe a)         -- no longer accepted
          type T = Just Nothing :: Maybe (Maybe a)   -- still accepted
      
        The latter form is a workaround due to temporary lack of an explicit
        quantification method. Ideally, we would write something along these
        lines:
      
          type T @a = Just (Nothing :: Maybe a)
      
        Related function: RnTypes.extractHsTyRdrTyVarsKindVars
      
      * Named wildcards in kinds are fixed (Trac #16334):
      
          x :: (Int :: _t)    -- this compiles, infers (_t ~ Type)
      
        Related function: RnTypes.partition_nwcs
      
      Implementation notes
      --------------------
      
      * One of the key changes is the removal of FKTV in RnTypes:
      
        - data FreeKiTyVars = FKTV { fktv_kis    :: [Located RdrName]
        -                          , fktv_tys    :: [Located RdrName] }
        + type FreeKiTyVars = [Located RdrName]
      
        We used to keep track of type and kind variables separately, but
        now that they are on equal footing when it comes to scoping, we
        can put them in the same list.
      
      * extract_lty and family are no longer parametrized by TypeOrKind,
        as we now do not distinguish kind variables from type variables.
      
      * PatSynExPE and the related Note [Pattern synonym existentials do not scope]
        have been removed (Trac #16315). With no implicit kind quantification,
        we can no longer trigger the error.
      
      * reportFloatingKvs and the related Note [Free-floating kind vars]
        have been removed. With no implicit kind quantification,
        we can no longer trigger the error.
      5bc195b1
  8. 25 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Fix the ghci063 test on Darwin (Trac #16201) · f320f3b2
      Vladislav Zavialov authored
      We use "touch -r" to set modification timestamps, which leads to precision loss
      on Darwin. For example,
      
         before: 2019-02-25 01:11:23.807627350 +0300
         after:  2019-02-25 01:11:23.807627000 +0300
                                           ^^^
      This means we can't trick GHCi into thinking the file hasn't been changed by
      restoring its old timestamp, as we cannot faithfully restore all digits.
      
      The solution is to nullify the insignificant digits before the first :load
      f320f3b2
  9. 24 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Expression/command ambiguity resolution · e61f6e35
      Vladislav Zavialov authored
      This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
      introducing a new ambiguity resolution system in the parser.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a command:
      
      	proc x -> do { (stuff) -< x }   -- 'stuff' is an expression
      	proc x -> do { (stuff) }        -- 'stuff' is a command
      
      Until we encounter arrow syntax (-<) we don't know whether to parse
      'stuff' as an expression or a command.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
      
      This meant polluting 'HsExpr' with command-related constructors. In
      other words, limitations of the parser were affecting the AST, and
      all other code (the renamer, the typechecker) had to deal with these
      extra constructors by panicking.
      
      We fix this abstraction leak by parsing into an intermediate
      representation, 'ExpCmd':
      
      	data ExpCmdG b where
      	  ExpG :: ExpCmdG HsExpr
      	  CmdG :: ExpCmdG HsCmd
      
      	type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
      
      	checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
      	checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
      	checkExp f = f ExpG  -- interpret as an expression
      	checkCmd f = f CmdG  -- interpret as a command
      
      See Note [Ambiguous syntactic categories] for details.
      
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/command ambiguity.
      
      Future work: apply the same principles to the expression/pattern
      ambiguity.
      e61f6e35
  10. 14 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Fail fast in solveLocalEqualities · 5c1f268e
      Simon Peyton Jones authored
      This patch makes us fail fast in TcSimplify.solveLocalEqualities,
      and in TcHsType.tc_hs_sig_type, if there are insoluble constraints.
      
      Previously we ploughed on even if there were insoluble constraints,
      leading to a cascade of hard-to-understand type errors. Failing
      eagerly is much better; hence a lot of testsuite error message
      changes.  Eg if we have
                f :: [Maybe] -> blah
                f xs = e
      then trying typecheck 'f x = e' with an utterly bogus type
      is just asking for trouble.
      
      I can't quite remember what provoked me to make this change,
      but I think the error messages are notably improved, by
      removing confusing clutter and focusing on the real error.
      5c1f268e
  11. 12 Feb, 2019 1 commit
    • Ryan Scott's avatar
      Fix #16299 by deleting incorrect code from IfaceSyn · 8b476d82
      Ryan Scott authored
      GHCi's `:info` command was pretty-printing Haskell98-style data types
      with explicit return kinds if the return kind wasn't `Type`. This
      leads to bizarre output like this:
      
      ```
      λ> :i (##)
      data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##)
              -- Defined in ‘GHC.Prim’
      ```
      
      Or, with unlifted newtypes:
      
      ```
      λ> newtype T = MkT Int#
      λ> :i T
      newtype T :: TYPE 'IntRep = MkT Int#
              -- Defined at <interactive>:5:1
      ```
      
      The solution is simple: just delete one part from `IfaceSyn` where
      GHC mistakenly pretty-prints the return kinds for non-GADTs.
      8b476d82
  12. 31 Jan, 2019 1 commit
  13. 30 Jan, 2019 3 commits
  14. 23 Jan, 2019 1 commit
  15. 16 Jan, 2019 1 commit
    • Alec Theriault's avatar
      Fix tests for `integer-simple` · d2eb344a
      Alec Theriault authored
      A bunch of tests for `integer-simple` were now broken for a foolish reason:
      unlike the `integer-gmp` case, there is no CorePrep optimization for turning
      small integers directly into applications of `S#`.
      
      Rather than port this optimization to `integer-simple` (which would involve
      moving a bunch of `integer-simple` names into `PrelNames`), I switched
      as many tests as possible to use `Int`.
      
      The printing of `Integer` is already tested in `print037`.
      d2eb344a
  16. 13 Jan, 2019 1 commit
    • Ömer Sinan Ağacan's avatar
      Refactor GHCi UI to fix #11606, #12091, #15721, #16096 · a34ee615
      Ömer Sinan Ağacan authored
      Instead of parsing and executing a statement or declaration directly we
      now parse them first and then execute in a separate step. This gives us
      the flexibility to inspect the parsed declaration before execution.
      Using this we now inspect parsed declarations, and if it's a single
      declaration of form `x = y` we execute it as `let x = y` instead, fixing
      a ton of problems caused by poor declaration support in GHCi.
      
      To avoid any users of the modules I left `execStmt` and `runDecls`
      unchanged and added `execStmt'` and `runDecls'` which work on parsed
      statements/declarations.
      a34ee615
  17. 03 Jan, 2019 1 commit
    • My Nguyen's avatar
      Visible kind application · 17bd1635
      My Nguyen authored
      Summary:
      This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
      It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
      written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
      application, just like in term-level.
      
      There are a few remaining issues with this patch, as documented in
      ticket #16082.
      
      Includes a submodule update for Haddock.
      
      Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a
      
      Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack
      
      Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter
      
      GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`
      
      Differential Revision: https://phabricator.haskell.org/D5229
      17bd1635
  18. 19 Dec, 2018 2 commits
    • Ryan Scott's avatar
      Fix #16030 by refactoring IfaceSyn's treatment of GADT constructors · 9d9e3557
      Ryan Scott authored
      Summary:
      GHCi's `:info` command was pretty-printined GADT
      constructors suboptimally in the following ways:
      
      1. Sometimes, fields were parenthesized when they did not need it,
         e.g.,
      
      ```lang=haskell
      data Foo a where
        MkFoo :: (Maybe a) -> Foo a
      ```
      
         I fixed this by refactoring some code in `pprIfaceConDecl` to be a
         little smarter with respect to GADT syntax. See `pprFieldArgTy`
         and `pprArgTy`.
      2. With `-fprint-explicit-kinds` enabled, there would be times when
         specified arguments would be printed without a leading `@` in GADT
         return types, e.g.,
      
      ```lang=haskell
      data Bar @k (a :: k) where
        MkBar :: Bar k a
      ```
      
         It turns out that `ppr_tc_app`, the function which pretty-prints
         these return types, was not using the proper machinery to print
         out the arguments, which caused the visibilities to be forgotten
         entirely. I refactored `ppr_tc_app` to do this correctly.
      
      Test Plan: make test TEST=T16030
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #16030
      
      Differential Revision: https://phabricator.haskell.org/D5440
      9d9e3557
    • Krzysztof Gogolewski's avatar
      Use unicode arrows with -fprint-unicode-syntax · d555d4be
      Krzysztof Gogolewski authored
      Summary:
      See #8959, this is one more place where we
      can pretty-print Unicode syntax.
      
      Test Plan: validate
      
      Reviewers: nomeata, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #8959
      
      Differential Revision: https://phabricator.haskell.org/D5439
      d555d4be
  19. 18 Dec, 2018 1 commit
  20. 13 Dec, 2018 1 commit
  21. 29 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
      
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
      
          Finish fix for #14880.
      
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      
      Kind inference for types and classes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
      
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      
      Quantification
      ~~~~~~~~~~~~~~
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
      
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
      
        And candidateQTyVars no longer needs a gbl_tvs argument.
      
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      
      Type families
      ~~~~~~~~~~~~~~
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      
      * I got rid of kcDataDefn entirely, quite a big function.
      
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      
      tcInferApps and friends
      ~~~~~~~~~~~~~~~~~~~~~~~
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
      
        Result: tcInferApps is now pretty comprehensible again.
      
      * I refactored the many function in TcMType that instantiate skolems.
      
      Smaller things
      
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      
      * I killed off quantifyConDecl, instead calling kindGeneralize
        directly.
      
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      
      Some other oddments
      
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      
      This patch fixes a raft of bugs, and includes tests for them.
      
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
      2257a86d
  22. 26 Nov, 2018 2 commits
    • Ryan Scott's avatar
      Fix #15941 by only special-casing visible infix applications · 984b75de
      Ryan Scott authored
      Summary:
      The iface pretty-printer had a special case for an
      application of an infix type constructor to two arguments. But this
      didn't take the visibilities of the arguments into account, which
      could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when
      `-fprint-explicit-kinds` was enabled (#15941). The fix is relatively
      straightforward: simply plumb through the visibilities of each
      argument, and only trigger the special case for infix applications
      if both arguments are visible (i.e., required).
      
      Test Plan: make test TEST=T15941
      
      Reviewers: goldfire, bgamari, monoidal
      
      Reviewed By: goldfire, monoidal
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15941
      
      Differential Revision: https://phabricator.haskell.org/D5375
      984b75de
    • Ryan Scott's avatar
      Print explicit foralls in type family eqns when appropriate · f932b1aa
      Ryan Scott authored
      Summary:
      When `-fprint-explicit-foralls` is enabled, type family
      equations are either printed without an explict `forall` entirely,
      or with a bizarre square bracket syntax (in the case of closed type
      families). I find neither satisfying, so in this patch, I introduce
      support for printing explicit `forall`s in open type-family, closed
      type-family, and data-family equations when appropriate. (By "when
      appropriate", I refer to the conditions laid out in
      `Note [When to print foralls]` in `IfaceType`.)
      
      One tricky point in the implementation is that I had to pick a
      visibility for each type variable in a `CoAxiom`/`FamInst` in order
      to be able to pass it to `pprUserIfaceForAll` //et al.// Because
      the type variables in a type family instance equation can't be
      instantiated by the programmer anyway, the choice only really matters
      for pretty-printing purposes, so I simply went with good ol'
      trustworthy `Specified`. (This design choice is documented in
      `Note [Printing foralls in type family instances]` in `IfaceType`.)
      
      Test Plan: make test TEST=T15827
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15827
      
      Differential Revision: https://phabricator.haskell.org/D5282
      f932b1aa
  23. 22 Nov, 2018 2 commits
    • Ryan Scott's avatar
      Overhaul -fprint-explicit-kinds to use VKA · f5d20838
      Ryan Scott authored
      This patch changes the behavior of `-fprint-explicit-kinds`
      so that it displays kind argument using visible kind application.
      In other words, the flag now:
      
      1. Prints instantiations of specified variables with `@(...)`.
      2. Prints instantiations of inferred variables with `@{...}`.
      
      In addition, this patch removes the `Use -fprint-explicit-kinds to
      see the kind arguments` error message that often arises when a type
      mismatch occurs due to different kinds. Instead, whenever there is a
      kind mismatch, we now enable the `-fprint-explicit-kinds` flag
      locally to help cue to the programmer where the error lies.
      (See `Note [Kind arguments in error messages]` in `TcErrors`.)
      As a result, these funny `@{...}` things can now appear to the user
      even without turning on the `-fprint-explicit-kinds` flag explicitly,
      so I took the liberty of documenting them in the users' guide.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15871
      
      Differential Revision: https://phabricator.haskell.org/D5314
      f5d20838
    • Tamar Christina's avatar
      testuite: update more windows tests outputs · 67277e7c
      Tamar Christina authored
      Test Plan: ./validate
      
      Reviewers: bgamari, simonmar
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5362
      67277e7c
  24. 17 Nov, 2018 1 commit
  25. 16 Nov, 2018 1 commit
  26. 15 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Smarter HsType pretty-print for promoted datacons · ae2c9b40
      Simon Peyton Jones authored
      Fix Trac #15898, by being smarter about when to print
      a space before a promoted data constructor, in a HsType.
      I had to implement a mildly tiresome function
          HsType.lhsTypeHasLeadingPromotionQuote
      It has multiple cases, of course, but it's very simple.
      
      The patch improves the error-message output in a bunch of
      cases, and (to my surprise) actually fixes a bug in the
      output of T14343 (Trac #14343), thus
      
        -  In the expression: _ :: Proxy '('( 'True,  'False),  'False)
        +  In the expression: _ :: Proxy '( '( 'True, 'False), 'False)
      
      I discovered that there were two copies of the PromotionFlag
      type (a boolean, with helpfully named data cons), one in
      IfaceType and one in HsType.  So I combined into one,
      PromotionFlag, and moved it to BasicTypes.  That's why
      quite a few files are touched, but it's all routine.
      ae2c9b40
  27. 01 Nov, 2018 1 commit
    • Zhou Fangyi's avatar
      Data.Maybe: add callstack for fromJust (Trac #15559) · 614028e3
      Zhou Fangyi authored
      Per feature request, add `HasCallStack` to `fromJust` in `Data.Maybe`
      and use `error` instead of `errorWithoutStackTrace`. This allows
      `fromJust` to print call stacks when throwing the error.
      
      Also add a new test case for the behaviour, modify existing test cases
      for new signature
      
      Test Plan: New test cases
      
      Reviewers: hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: ulysses4ever, rwbarton, carter
      
      GHC Trac Issues: #15559
      
      Differential Revision: https://phabricator.haskell.org/D5256
      614028e3
  28. 29 Oct, 2018 1 commit
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      
      As a bonus, we now have more control over the ordering of such
      skolems.
      
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      
      Test cases: dependent/should_fail/T14880{,-2},
                  dependent/should_fail/T15743[cd]
                  dependent/should_compile/T15743{,e}
                  ghci/scripts/T15743b
                  polykinds/T15592
                  dependent/should_fail/T15591[bc]
                  ghci/scripts/T15591
      5e45ad10
  29. 24 Oct, 2018 1 commit
    • Alec Theriault's avatar
      Trigger multiline mode in GHCi on '\case' (#13087) · eaf15934
      Alec Theriault authored
      Summary:
      In ALR, 'ITlcase' should expect an opening curly. This is probably a forgotten
      edge case in ALR, since `maybe_layout` (which handles the non-ALR layout)
      already deals with the 'ITlcase' token properly.
      
      Test Plan: make TEST=T10453 && make TEST=T13087
      
      Reviewers: bgamari, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: RyanGlScott, rwbarton, carter
      
      GHC Trac Issues: #10453, #13087
      
      Differential Revision: https://phabricator.haskell.org/D5236
      eaf15934
  30. 15 Oct, 2018 1 commit
    • Vladislav Zavialov's avatar
      Enable -Wcompat=error in the testsuite · 165d3d5d
      Vladislav Zavialov authored
      Enabling -Werror=compat in the testsuite allows us to easily see the
      impact that a new warning has on code. It also means that in the period
      between adding the warning and making the actual breaking change, all
      new test cases that are being added to the testsuite will be
      forwards-compatible. This is good because it will make the actual
      breaking change contain less irrelevant testsuite updates.
      
      Things that -Wcompat warns about are things that are going to break in
      the future, so we can be proactive and keep our testsuite
      forwards-compatible.
      
      This patch consists of two main changes:
      
      * Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration.
      * Fix all broken test cases.
      
      Test Plan: Validate
      
      Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott
      
      Reviewed By: goldfire, RyanGlScott
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15278
      
      Differential Revision: https://phabricator.haskell.org/D5200
      165d3d5d
  31. 04 Oct, 2018 2 commits
    • Alec Theriault's avatar
      Set `infixr -1 ->` · 251e3424
      Alec Theriault authored
      Summary:
      This simply makes explicit what is already the case. Due to special
      treatment in the parser, `->` has the lowest fixity. This patch propagates
      that information to:
      
        * GHCi, where `:info ->` now return the right fixity
        * TH, where `reifyFixity` returns the right fixity
        * the generated sources for `GHC.Prim`
      
      See #15235.
      
      Test Plan: make test
      
      Reviewers: bgamari, alanz, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: int-index, RyanGlScott, rwbarton, mpickering, carter
      
      GHC Trac Issues: #15235
      
      Differential Revision: https://phabricator.haskell.org/D5199
      251e3424
    • Simon Peyton Jones's avatar
      Better pretty-printing of forall types · 37ef7031
      Simon Peyton Jones authored
      Currently forall-types with a lot of type variables,
      or type variables with big kinds, are pretty-printed too
      horizontally, and dribble off to the right in an illegible
      way.
      
      This patch treats the type variables as a group, and uses
      'fsep' to lay them out decently.
      37ef7031