1. 18 Sep, 2018 1 commit
  2. 17 Sep, 2018 1 commit
  3. 13 Sep, 2018 1 commit
  4. 07 Sep, 2018 2 commits
    • Takenobu Tani's avatar
      users-guide: Disable syntax highlighting · 2b6694a5
      Takenobu Tani authored
      Summary:
      I disabled syntax highlighting for NumericUnderscores extension.
      
      Because pygments does not yet correspond to syntax rule for NumericUnderscores.
      (Sphinx uses pygments as the syntax highlighting.)
      
      I've sent a pull-request to pygments project[1].
      But development of pygments has been suspended since 2017 March.
      
      [1]: https://bitbucket.org/birkenfeld/pygments-main/pull-requests/
             745/fix-haskell-lexer-for-numeric-literals/diff
      
      [ci skip]
      
      Test Plan: build
      
      Reviewers: bgamari, monoidal
      
      Reviewed By: monoidal
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5120
      2b6694a5
    • Krzysztof Gogolewski's avatar
      Documentation tweaks · 4caad166
      Krzysztof Gogolewski authored
      Summary:
      - Mention static pointers in "stolen syntax"
      - Suggest importing Constraint and IsString from Data.* instead of GHC.*
      - Remove obsolete SPECIALISE syntax; it was removed in or before 1999
        (d66d409b)
      - Fix link in pattern signatures
      
      Test Plan: build
      
      Reviewers: bgamari, takenobu
      
      Reviewed By: takenobu
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5132
      4caad166
  5. 03 Sep, 2018 1 commit
  6. 28 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Rename kind vars in left-to-right order in bindHsQTyVars · 102284e7
      Ryan Scott authored
      Summary:
      When renaming kind variables in an `LHsQTyVars`, we were
      erroneously putting all of the kind variables in the binders
      //after// the kind variables in the body, resulting in #15568. The
      fix is simple: just swap the order of these two around.
      
      Test Plan: make test TEST=T15568
      
      Reviewers: simonpj, bgamari, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, carter
      
      GHC Trac Issues: #15568
      
      Differential Revision: https://phabricator.haskell.org/D5108
      102284e7
  7. 07 Aug, 2018 1 commit
    • Herbert Valerio Riedel's avatar
      Turn on MonadFail desugaring by default · aab8656b
      Herbert Valerio Riedel authored
      Summary:
      This contains two commits:
      
      ----
      
      Make GHC's code-base compatible w/ `MonadFail`
      
      There were a couple of use-sites which implicitly used pattern-matches
      in `do`-notation even though the underlying `Monad` didn't explicitly
      support `fail`
      
      This refactoring turns those use-sites into explicit case
      discrimations and adds an `MonadFail` instance for `UniqSM`
      (`UniqSM` was the worst offender so this has been postponed for a
      follow-up refactoring)
      
      ---
      
      Turn on MonadFail desugaring by default
      
      This finally implements the phase scheduled for GHC 8.6 according to
      
      https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Transitionalstrategy
      
      This also preserves some tests that assumed MonadFail desugaring to be
      active; all ghc boot libs were already made compatible with this
      `MonadFail` long ago, so no changes were needed there.
      
      Test Plan: Locally performed ./validate --fast
      
      Reviewers: bgamari, simonmar, jrtc27, RyanGlScott
      
      Reviewed By: bgamari
      
      Subscribers: bgamari, RyanGlScott, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D5028
      aab8656b
  8. 06 Aug, 2018 1 commit
  9. 02 Aug, 2018 1 commit
    • Richard Eisenberg's avatar
      Remove decideKindGeneralisationPlan · c955a514
      Richard Eisenberg authored
      TypeInType came with a new function: decideKindGeneralisationPlan.
      This type-level counterpart to the term-level decideGeneralisationPlan
      chose whether or not a kind should be generalized. The thinking was
      that if `let` should not be generalized, then kinds shouldn't either
      (under the same circumstances around -XMonoLocalBinds).
      
      However, this is too conservative -- the situation described in the
      motivation for "let should be be generalized" does not occur in types.
      
      This commit thus removes decideKindGeneralisationPlan, always
      generalizing.
      
      One consequence is that tc_hs_sig_type_and_gen no longer calls
      solveEqualities, which reports all unsolved constraints, instead
      relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect
      of this is that reporing kind errors gets delayed more frequently.
      This seems to be a net benefit in error reporting; often, alongside
      a kind error, the type error is now reported (and users might find
      type errors easier to understand).
      
      Some of these errors ended up at the top level, where it was
      discovered that the GlobalRdrEnv containing the definitions in the
      local module was not in the TcGblEnv, and thus errors were reported
      with qualified names unnecessarily. This commit rejiggers some of
      the logic around captureTopConstraints accordingly.
      
      One error message (typecheck/should_fail/T1633)
      is a regression, mentioning the name of a default method. However,
      that problem is already reported as #10087, its solution is far from
      clear, and so I'm not addressing it here.
      
      This commit fixes #15141. As it's an internal refactor, there is
      no concrete test case for it.
      
      Along the way, we no longer need the hsib_closed field of
      HsImplicitBndrs (it was used only in decideKindGeneralisationPlan)
      and so it's been removed, simplifying the datatype structure.
      
      Along the way, I removed code in the validity checker that looks
      at coercions. This isn't related to this patch, really (though
      it was, at one point), but it's an improvement, so I kept it.
      
      This updates the haddock submodule.
      c955a514
  10. 17 Jul, 2018 1 commit
  11. 16 Jul, 2018 1 commit
    • Vladislav Zavialov's avatar
      Do not imply NoStarIsType by TypeOperators/TypeInType · 65c186f0
      Vladislav Zavialov authored
      Implementation of the "Embrace TypeInType" proposal was done according
      to the spec, which specified that TypeOperators must imply NoStarIsType.
      This implication was meant to prevent breakage and to be removed in 2
      releases.  However, compiling head.hackage has shown that this
      implication only magnified the breakage, so there is no reason to have
      it in the first place.
      
      To remain in compliance with the three-release policy, we add a
      workaround to define the (*) type operator even when -XStarIsType is on.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, RyanGlScott, goldfire, phadej, hvr
      
      Reviewed By: bgamari, RyanGlScott
      
      Subscribers: harpocrates, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4865
      65c186f0
  12. 12 Jul, 2018 3 commits
    • 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`
      command.
      
      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
      c4d98341
    • 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'.
      471a992a
    • Sasa Bogicevic's avatar
      Correct Simple to Complex wording · 5ee9a1cd
      Sasa Bogicevic authored
      5ee9a1cd
  13. 10 Jul, 2018 2 commits
  14. 06 Jul, 2018 1 commit
  15. 20 Jun, 2018 1 commit
  16. 17 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Provide a better error message for unpromotable data constructor contexts · c6375411
      Ryan Scott authored
      Trac #14845 brought to light a corner case where a data
      constructor could not be promoted (even with `-XTypeInType`) due to
      an unpromotable constraint in its context. However, the error message
      was less than helpful, so this patch adds an additional check to
      `tcTyVar` catch unpromotable data constructors like these //before//
      they're promoted, and to give a sensible error message in such cases.
      
      Test Plan: make test TEST="T13895 T14845"
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13895, #14845
      
      Differential Revision: https://phabricator.haskell.org/D4728
      c6375411
  17. 16 Jun, 2018 1 commit
    • Richard Eisenberg's avatar
      Quantify unfixed kind variables in CUSKs · 12794287
      Richard Eisenberg authored
      This is a small change in user-facing behavior. When we
      have a unification variable left over in a CUSK, we previously
      would issue an error. But, we can just quantify. This also
      teaches kcLHsQTyVars to use quantifyTyVars instead of its own,
      ad-hoc quantification scheme.
      
      Fixes #15273.
      
      test case: polykinds/T11648b
      12794287
  18. 15 Jun, 2018 1 commit
  19. 14 Jun, 2018 4 commits
    • Nathan Collins's avatar
      3a18a82f
    • Vladislav Zavialov's avatar
      Embrace -XTypeInType, add -XStarIsType · d650729f
      Vladislav Zavialov authored
      Summary:
      Implement the "Embrace Type :: Type" GHC proposal,
      .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst
      
      GHC 8.0 included a major change to GHC's type system: the Type :: Type
      axiom. Though casual users were protected from this by hiding its
      features behind the -XTypeInType extension, all programs written in GHC
      8+ have the axiom behind the scenes. In order to preserve backward
      compatibility, various legacy features were left unchanged. For example,
      with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
      Now these restrictions are lifted and -XTypeInType becomes a redundant
      flag that will be eventually deprecated.
      
      * Incorporate the features currently in -XTypeInType into the
        -XPolyKinds and -XDataKinds extensions.
      * Introduce a new extension -XStarIsType to control how to parse * in
        code and whether to print it in error messages.
      
      Test Plan: Validate
      
      Reviewers: goldfire, hvr, bgamari, alanz, simonpj
      
      Reviewed By: goldfire, ...
      d650729f
    • Ben Gamari's avatar
      4672e2eb
    • Takenobu Tani's avatar
      users-guide: Fix PtrRepLifted to LiftedRep · 87d691c0
      Takenobu Tani authored
      Fix `TYPE 'PtrRepLifted` to `TYPE 'LiftedRep`
      
      [ci skip]
      
      Test Plan: build
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4818
      87d691c0
  20. 10 Jun, 2018 1 commit
  21. 08 Jun, 2018 2 commits
  22. 07 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Document #15079 in the users' guide · bc9a838a
      Ryan Scott authored
      Trac #15079 revealed an interesting limitation in the interaction
      between variable visibility and higher-rank kinds. We (Richard and I)
      came to the conclusion that this is an acceptable (albeit surprising)
      limitation, so this documents in the users' guide to hopefully eliminate
      some confusion for others in the future.
      
      Test Plan: Read it
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15079
      
      Differential Revision: https://phabricator.haskell.org/D4803
      bc9a838a
  23. 05 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Introduce DerivingVia · 8ed8b037
      Ryan Scott authored
      This implements the `DerivingVia` proposal put forth in
      https://github.com/ghc-proposals/ghc-proposals/pull/120.
      
      This introduces the `DerivingVia` deriving strategy. This is a
      generalization of `GeneralizedNewtypeDeriving` that permits the user
      to specify the type to `coerce` from.
      
      The major change in this patch is the introduction of the
      `ViaStrategy` constructor to `DerivStrategy`, which takes a type
      as a field. As a result, `DerivStrategy` is no longer a simple
      enumeration type, but rather something that must be renamed and
      typechecked. The process by which this is done is explained more
      thoroughly in section 3 of this paper
      ( https://www.kosmikus.org/DerivingVia/deriving-via-paper.pdf ),
      although I have inlined the relevant parts into Notes where possible.
      
      There are some knock-on changes as well. I took the opportunity to
      do some refactoring of code in `TcDeriv`, especially the
      `mkNewTypeEqn` function, since it was bundling all of the logic for
      (1) deriving instances for newtypes and
      (2) `GeneralizedNewtypeDeriving`
      into one huge broth. `DerivingVia` reuses much of part (2), so that
      was factored out as much as possible.
      
      Bumps the Haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, bgamari, goldfire, alanz
      
      Subscribers: alanz, goldfire, rwbarton, thomie, mpickering, carter
      
      GHC Trac Issues: #15178
      
      Differential Revision: https://phabricator.haskell.org/D4684
      8ed8b037
  24. 04 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Implement QuantifiedConstraints · 7df58960
      Simon Peyton Jones authored
      We have wanted quantified constraints for ages and, as I hoped,
      they proved remarkably simple to implement.   All the machinery was
      already in place.
      
      The main ticket is Trac #2893, but also relevant are
        #5927
        #8516
        #9123 (especially!  higher kinded roles)
        #14070
        #14317
      
      The wiki page is
        https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints
      which in turn contains a link to the GHC Proposal where the change
      is specified.
      
      Here is the relevant Note:
      
      Note [Quantified constraints]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      The -XQuantifiedConstraints extension allows type-class contexts like
      this:
      
        data Rose f x = Rose x (f (Rose f x))
      
        instance (Eq a, forall b. Eq b => Eq (f b))
              => Eq (Rose f a)  where
          (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2
      
      Note the (forall b. Eq b => Eq (f b)) in the instance contexts.
      This quantified constraint is needed to solve the
       [W] (Eq (f (Rose f x)))
      constraint which arises form the (==) definition.
      
      Here are the moving parts
        * Language extension {-# LANGUAGE QuantifiedConstraints #-}
          and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension
      
        * A new form of evidence, EvDFun, that is used to discharge
          such wanted constraints
      
        * checkValidType gets some changes to accept forall-constraints
          only in the right places.
      
        * Type.PredTree gets a new constructor ForAllPred, and
          and classifyPredType analyses a PredType to decompose
          the new forall-constraints
      
        * Define a type TcRnTypes.QCInst, which holds a given
          quantified constraint in the inert set
      
        * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst],
          which holds all the Given forall-constraints.  In effect,
          such Given constraints are like local instance decls.
      
        * When trying to solve a class constraint, via
          TcInteract.matchInstEnv, use the InstEnv from inert_insts
          so that we include the local Given forall-constraints
          in the lookup.  (See TcSMonad.getInstEnvs.)
      
        * topReactionsStage calls doTopReactOther for CIrredCan and
          CTyEqCan, so they can try to react with any given
          quantified constraints (TcInteract.matchLocalInst)
      
        * TcCanonical.canForAll deals with solving a
          forall-constraint.  See
             Note [Solving a Wanted forall-constraint]
             Note [Solving a Wanted forall-constraint]
      
        * We augment the kick-out code to kick out an inert
          forall constraint if it can be rewritten by a new
          type equality; see TcSMonad.kick_out_rewritable
      
      Some other related refactoring
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Move SCC on evidence bindings to post-desugaring, which fixed
        #14735, and is generally nicer anyway because we can use
        existing CoreSyn free-var functions.  (Quantified constraints
        made the free-vars of an ev-term a bit more complicated.)
      
      * In LookupInstResult, replace GenInst with OneInst and NotSure,
        using the latter for multiple matches and/or one or more
        unifiers
      7df58960
  25. 03 Jun, 2018 1 commit
  26. 02 Jun, 2018 1 commit
    • Ben Gamari's avatar
      vectorise: Put it out of its misery · faee23bb
      Ben Gamari authored
      Poor DPH and its vectoriser have long been languishing; sadly it seems there is
      little chance that the effort will be rekindled. Every few years we discuss
      what to do with this mass of code and at least once we have agreed that it
      should be archived on a branch and removed from `master`. Here we do just that,
      eliminating heaps of dead code in the process.
      
      Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and
      `primitive` submodules.
      
      Test Plan: Validate
      
      Reviewers: simonpj, simonmar, hvr, goldfire, alanz
      
      Reviewed By: simonmar
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4761
      faee23bb
  27. 30 May, 2018 3 commits
    • Matthías Páll Gissurarson's avatar
      Improved Valid Hole Fits · e0b44e2e
      Matthías Páll Gissurarson authored
      I've changed the name from `Valid substitutions` to `Valid hole fits`,
      since "substitution" already has a well defined meaning within the
      theory. As part of this change, the flags and output is reanamed, with
      substitution turning into hole-fit in most cases. "hole fit" was already
      used internally in the code, it's clear and shouldn't cause any
      confusion.
      
      In this update, I've also reworked how we manage side-effects in the
      hole we are considering.
      
      This allows us to consider local bindings such as where clauses and
      arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
      :: [a] -> a`.
      
      It also allows us to find suggestions such as `maximum` for holes of
      type `Ord a => a -> [a]`, and `max` when looking for a match for the
      hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.
      
      We also show much improved output for refinement hole fits, and
      fixes #14990. We now show the correct type of the function, but we also
      now show what the arguments to the function should be e.g. `foldl1 (_ ::
      Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.
      
      I've moved the bulk of the code from `TcErrors.hs` to a new file,
      `TcHoleErrors.hs`, since it was getting too big to not live on it's own.
      
      This addresses the considerations raised in #14969, and takes proper
      care to set the `tcLevel` of the variables to the right level before
      passing it to the simplifier.
      
      We now also zonk the suggestions properly, which improves the output of
      the refinement hole fits considerably.
      
      This also filters out suggestions from the `GHC.Err` module, since even
      though `error` and `undefined` are indeed valid hole fits, they are
      "trivial", and almost never useful to the user.
      
      We now find the hole fits using the proper manner, namely by solving
      nested implications. This entails that the givens are passed along using
      the implications the hole was nested in, which in turn should mean that
      there will be fewer weird bugs in the typed holes.
      
      I've also added a new sorting method (as suggested by SPJ) and sort by
      the size of the types needed to turn the hole fits into the type of the
      hole. This gives a reasonable approximation to relevance, and is much
      faster than the subsumption check. I've also added a flag to toggle
      whether to use this new sorting algorithm (as is done by default) or the
      subsumption algorithm. This fixes #14969
      
      I've also added documentation for these new flags and update the
      documentation according to the new output.
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14969, #14990, #10946
      
      Differential Revision: https://phabricator.haskell.org/D4444
      e0b44e2e
    • Ben Gamari's avatar
      users-guide: Point out GNTD may require additional extensions · b876c1bb
      Ben Gamari authored
      As noted in #15073, GeneralizedNewtypeDeriving may produce code that
      uses extensions that do not directly appear in the code written by the
      user.  Make this clear in the users guide.
      
      [skip ci]
      
      Test Plan: Read it
      
      Reviewers: RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: fosskers, rwbarton, thomie, carter
      
      GHC Trac Issues: #15073
      
      Differential Revision: https://phabricator.haskell.org/D4701
      b876c1bb
    • AntC's avatar
      Improve the documentation of lexically scoped type variables · 2ea93a7d
      AntC authored
      Section 10.16 in the Users Guide. Also reviewed mentions/links from
      other sections: none need revision.
      
      Fixes #15146.
      2ea93a7d
  28. 05 May, 2018 1 commit
  29. 17 Apr, 2018 1 commit
  30. 13 Apr, 2018 1 commit