1. 12 Jul, 2018 13 commits
    • Michael Sloan's avatar
      Fix handling of ApplicativeDo in TH AST quotes · 234093cf
      Michael Sloan authored
      See https://ghc.haskell.org/trac/ghc/ticket/14471
      Also fixes a parenthesization bug in pprStmt when ret_stripped is True
      Test Plan: tests added to testsuite
      Trac issues: #14471
      Reviewers: goldfire, bgamari
      Reviewed By: goldfire
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4912
    • Matthías Páll Gissurarson's avatar
      Add flag to show docs of valid hole fits · c4d98341
      Matthías Páll Gissurarson authored
      One issue with valid hole fits is that the function names can often be
      opaque for the uninitiated, such as `($)`. This diff adds a new flag,
      `-fshow-docs-of-hole-fits` that adds the documentation of the identifier
      in question to the message, using the same mechanism as the `:doc`
      As an example, with this flag enabled, the valid hole fits for `_ ::
      [Int] -> Int` will include:
      Valid hole fits include
        head :: forall a. [a] -> a
          {-^ Extract the first element of a list, which must be non-empty.-}
          with head @Int
          (imported from ‘Prelude’ (and originally defined in ‘GHC.List’))
      And one of the refinement hole fits, `($) _`, will read:
      Valid refinement hole fits include
        ($) (_ :: [Int] -> Int)
            where ($) :: forall a b. (a -> b) -> a -> b
            {-^ Application operator.  This operator is redundant, since ordinary
                application @(f x)@ means the same as @(f '$' x)@. However, '$' has
                low, right-associative binding precedence, so it sometimes allows
                parentheses to be omitted; for example:
                > f $ g $ h x  =  f (g (h x))
                It is also useful in higher-order situations, such as @'map' ('$' 0) xs@,
                or @'Data.List.zipWith' ('$') fs xs@.
                Note that @($)@ is levity-polymorphic in its result type, so that
                    foo $ True    where  foo :: Bool -> Int#
                is well-typed-}
            with ($) @'GHC.Types.LiftedRep @[Int] @Int
            (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’))
      Another example of where documentation can come in very handy, is when
      working with the `lens` library.
      When you compile
      {-# OPTIONS_GHC -fno-show-provenance-of-hole-fits -fshow-docs-of-hole-fits #-}
      module LensDemo where
      import Control.Lens
      import Control.Monad.State
      newtype Test = Test { _value :: Int } deriving (Show)
      value :: Lens' Test Int
      value f (Test i) = Test <$> f i
      updTest :: Test -> Test
      updTest t = t &~ do
          _ value (1 :: Int)
      You get:
        Valid hole fits include
          (#=) :: forall s (m :: * -> *) a b.
                  MonadState s m =>
                  ALens s s a b -> b -> m ()
            {-^ A version of ('Control.Lens.Setter..=') that works on 'ALens'.-}
            with (#=) @Test @(StateT Test Identity) @Int @Int
          (<#=) :: forall s (m :: * -> *) a b.
                   MonadState s m =>
                   ALens s s a b -> b -> m b
            {-^ A version of ('Control.Lens.Setter.<.=') that works on 'ALens'.-}
            with (<#=) @Test @(StateT Test Identity) @Int @Int
          (<*=) :: forall s (m :: * -> *) a.
                   (MonadState s m, Num a) =>
                   LensLike' ((,) a) s a -> a -> m a
            {-^ Multiply the target of a numerically valued 'Lens' into your 'Monad''s
                state and return the result.
                When you do not need the result of the multiplication,
                ('Control.Lens.Setter.*=') is more flexible.
                ('<*=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a
                ('<*=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a
            with (<*=) @Test @(StateT Test Identity) @Int
          (<+=) :: forall s (m :: * -> *) a.
                   (MonadState s m, Num a) =>
                   LensLike' ((,) a) s a -> a -> m a
            {-^ Add to the target of a numerically valued 'Lens' into your 'Monad''s state
                and return the result.
                When you do not need the result of the addition,
                ('Control.Lens.Setter.+=') is more flexible.
                ('<+=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a
                ('<+=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a
            with (<+=) @Test @(StateT Test Identity) @Int
          (<-=) :: forall s (m :: * -> *) a.
                   (MonadState s m, Num a) =>
                   LensLike' ((,) a) s a -> a -> m a
            {-^ Subtract from the target of a numerically valued 'Lens' into your 'Monad''s
                state and return the result.
                When you do not need the result of the subtraction,
                ('Control.Lens.Setter.-=') is more flexible.
                ('<-=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a
                ('<-=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a
            with (<-=) @Test @(StateT Test Identity) @Int
          (<<*=) :: forall s (m :: * -> *) a.
                    (MonadState s m, Num a) =>
                    LensLike' ((,) a) s a -> a -> m a
            {-^ Modify the target of a 'Lens' into your 'Monad''s state by multipling a value
                and return the /old/ value that was replaced.
                When you do not need the result of the operation,
                ('Control.Lens.Setter.*=') is more flexible.
                ('<<*=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a
                ('<<*=') :: ('MonadState' s m, 'Num' a) => 'Iso'' s a -> a -> m a
            with (<<*=) @Test @(StateT Test Identity) @Int
          (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits)
      Which allows you to see at a glance what opaque operators like `(<<*=)`
      and `(<#=)` do.
      Reviewers: bgamari, sjakobi
      Reviewed By: sjakobi
      Subscribers: sjakobi, alexbiehl, rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4848
    • Neil Mitchell's avatar
      Make boot work if ACLOCAL_PATH is not set · 101e9047
      Neil Mitchell authored
    • Bodigrim's avatar
      Fix gcdExtInteger (trac#15350) · 7c207c86
      Bodigrim authored
    • Ningning Xie's avatar
    • AntC's avatar
      Trac #8581 users_guide/glasgow_exts section 10.7 · 471a992a
      AntC authored
      as per comments on the ticket; also linked to Haskell folk art of 'Smart constructors'.
    • Ben Gamari's avatar
      Bump xhtml submodule to 3000.2.2.1 · 8e51eced
      Ben Gamari authored
    • Alec Theriault's avatar
    • David Sanders's avatar
      Link to iterate' doesn't work. · 6a1e7e76
      David Sanders authored
    • Michael Sloan's avatar
      Attempt to fix travis build · 7527d1fe
      Michael Sloan authored
    • jhb563's avatar
      Adding missing 'no' · 00cb530c
      jhb563 authored
    • Sasa Bogicevic's avatar
      Correct Simple to Complex wording · 5ee9a1cd
      Sasa Bogicevic authored
    • Ömer Sinan Ağacan's avatar
      Minor refactoring in CmmUtils.mkLiveness · 3efd7cd9
      Ömer Sinan Ağacan authored
      Test Plan: validate
      Reviewers: bgamari, simonmar
      Reviewed By: simonmar
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4957
  2. 11 Jul, 2018 4 commits
    • Ryan Scott's avatar
      Use IfaceAppArgs to store an IfaceAppTy's arguments · 1c353623
      Ryan Scott authored
      Currently, an `IfaceAppTy` has no way to tell whether its
      argument is visible or not, so it simply treats all arguments as
      visible, leading to #15330. We already have a solution for this
      problem in the form of the `IfaceTcArgs` data structure, used by
      `IfaceTyConApp` to represent the arguments to a type constructor.
      Therefore, it makes sense to reuse this machinery for `IfaceAppTy`,
      so this patch does just that.
      This patch:
      1. Renames `IfaceTcArgs` to `IfaceAppArgs` to reflect its more
         general purpose.
      2. Changes the second field of `IfaceAppTy` from `IfaceType` to
         `IfaceAppArgs`, and propagates the necessary changes through. In
         particular, pretty-printing an `IfaceAppTy` now goes through the
         `IfaceAppArgs` pretty-printer, which correctly displays arguments
         as visible or not for free, fixing #15330.
      3. Changes `toIfaceTypeX` and related functions so that when
         converting an `AppTy` to an `IfaceAppTy`, it flattens as many
         argument `AppTy`s as possible, and then converts those arguments
         into an `IfaceAppArgs` list, using the kind of the function
         `Type` as a guide. (Doing so minimizes the number of times we need
         to call `typeKind`, which is more expensive that finding the kind
         of a `TyCon`.)
      Test Plan: make test TEST=T15330
      Reviewers: goldfire, simonpj, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15330
      Differential Revision: https://phabricator.haskell.org/D4938
    • Simon Peyton Jones's avatar
      Better Note [The well-kinded type invariant] · e24da5ed
      Simon Peyton Jones authored
      c.f. Trac #14873
    • Simon Peyton Jones's avatar
      Add test for Trac #15352 · 81d8b179
      Simon Peyton Jones authored
    • Richard Eisenberg's avatar
      Remove bad debugging output. · 9768c946
      Richard Eisenberg authored
      The removed line could cause GHC to hang by printing a
      knot-tied type.
  3. 10 Jul, 2018 10 commits
    • Richard Eisenberg's avatar
      Note [Ordering of implicit variables] · 7f4dd888
      Richard Eisenberg authored
      This addresses #14808
      [ci skip]
    • Richard Eisenberg's avatar
      Expand and implement Note [The tcType invariant] · cf67e59a
      Richard Eisenberg authored
      Read that note -- it's necessary to make sure that we can
      always call typeKind without panicking. As discussed on #14873,
      there were more checks and zonking to do, implemented here.
      There are no known bugs fixed by this patch, but there are likely
      unknown ones.
    • Richard Eisenberg's avatar
      Kind-check CUSK associated types separately · 030211d2
      Richard Eisenberg authored
      Previously, we kind-checked associated types while while still
      figuring out the kind of a CUSK class. This caused trouble, as
      documented in Note [Don't process associated types in kcLHsQTyVars]
      in TcTyClsDecls. This commit moves this process after the initial
      kind of the class is determined.
      Fixes #15142.
      Test case: indexed-types/should_compile/T15142.hs
    • Richard Eisenberg's avatar
      Unwrap casts before checking vars in eager unifier · 042df603
      Richard Eisenberg authored
      Previously, checking whether (tv |> co) ~ (tv |> co) got deferred,
      because we looked for vars before stripping casts. (The left type
      would get stripped, and then tv ~ (tv |> co) would scare the occurs-
      This opportunity for improvement presented itself in other work.
      This is just an optimization. Some programs can now report more
      errors simultaneously.
    • Simon Peyton Jones's avatar
      Optional context for a quantified constraint · 8ec29460
      Simon Peyton Jones authored
      This is a documentation-only fix, addressing Trac #15354.
    • Simon Peyton Jones's avatar
      Add nakedSubstTy and use it in TcHsType.tcInferApps · 5067b205
      Simon Peyton Jones authored
      This was a tricky one.
      During type checking we maintain TcType:
         Note [The well-kinded type invariant]
      That is, types are well-kinded /without/ zonking.
      But in tcInferApps we were destroying that invariant by calling
      substTy, which in turn uses smart constructors, which eliminate
      apparently-redundant Refl casts.
      This is horribly hard to debug beause they really are Refls and
      so it "ought" to be OK to discard them. But it isn't, as the
      above Note describes in some detail.
      Maybe we should review the invariant?  But for now I just followed
      it, tricky thought it is.
      This popped up because (for some reason) when I fixed Trac #15343,
      that exposed this bug by making test polykinds/T14174a fail (in
      Trac #14174 which indeed has the same origin).
      So this patch fixes a long standing and very subtle bug.
      One interesting point: I defined nakedSubstTy in a few lines by
      using the generic mapType stuff.  I note that the "normal"
      TyCoRep.substTy does /not/ use mapType.  But perhaps it should:
      substTy has lots of $! strict applications in it, and they could
      all be eliminated just by useing the StrictIdentity monad.  And
      that'd make it much easier to experiment with switching between
      strict and lazy versions.
    • Simon Peyton Jones's avatar
      More tc-tracing · 03d72683
      Simon Peyton Jones authored
      And I added some HasDebugCallStack constraints to tcExpectedKind
      and related functions too.
    • Simon Peyton Jones's avatar
      Fix decompsePiCos and visible type application · aedbf7f1
      Simon Peyton Jones authored
      Trac #15343 was caused by two things
      First, in TcHsType.tcHsTypeApp, which deals with the type argment
      in visible type application, we were failing to call
      solveLocalEqualities. But the type argument is like a user type
      signature so it's at least inconsitent not to do so.
      I thought that would nail it.  But it didn't. It turned out that we
      were ended up calling decomposePiCos on a type looking like this
          (f |> co) Int
      where co :: (forall a. ty) ~ (t1 -> t2)
      Now, 'co' is insoluble, and we'll report that later.  But meanwhile
      we don't want to crash in decomposePiCos.
      My fix involves keeping track of the type on both sides of the
      coercion, and ensuring that the outer shape matches before
      decomposing.  I wish there was a simpler way to do this. But
      I think this one is at least robust.
      I suppose it is possible that the decomposePiCos fix would
      have cured the original report, but I'm leaving the one-line
      tcHsTypeApp fix in too because it just seems more consistent.
    • Simon Peyton Jones's avatar
      More refactoring in TcValidity · fd0f0334
      Simon Peyton Jones authored
      This patch responds to Trac #15334 by making it an error to
      write an instance declaration for a tuple constraint like
      (Eq [a], Show [a]).
      I then discovered that instance validity checking was
      scattered betweeen TcInstDcls and TcValidity, so I took
      the time to bring it all together, into
      In doing so I discovered that there are lot of special
      cases.   I have not changed them, but at least they are
      all laid out clearly now.
    • Ningning Xie's avatar
      Refactor coercion rule · 55a3f855
      Ningning Xie authored
      The patch is an attempt on #15192.
      It defines a new coercion rule
       | GRefl Role Type MCoercion
      which correspondes to the typing rule
           t1 : k1
        GRefl r t1 MRefl: t1 ~r t1
           t1 : k1       co :: k1 ~ k2
        GRefl r t1 (MCo co) : t1 ~r t1 |> co
      MCoercion wraps a coercion, which might be reflexive (MRefl)
      or not (MCo co). To know more about MCoercion see #14975.
      We keep Refl ty as a special case for nominal reflexive coercions,
      naemly, Refl ty :: ty ~n ty.
      This commit is meant to be a general performance improvement,
      but there are a few regressions. See #15192, comment:13 for
      more information.
      Test Plan: ./validate
      Reviewers: bgamari, goldfire, simonpj
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15192
      Differential Revision: https://phabricator.haskell.org/D4747
  4. 08 Jul, 2018 1 commit
  5. 06 Jul, 2018 11 commits
  6. 05 Jul, 2018 1 commit