 12 Jul, 2018 13 commits


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 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, `fshowdocsofholefits` 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 nonempty.} 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, rightassociative 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 higherorder situations, such as @'map' ('$' 0) xs@, or @'Data.List.zipWith' ('$') fs xs@. Note that @($)@ is levitypolymorphic in its result type, so that foo $ True where foo :: Bool > Int# is welltyped} 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 fnoshowprovenanceofholefits fshowdocsofholefits #} 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 fmaxvalidholefits=N or fnomaxvalidholefits) ``` 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 authored

Bodigrim authored

Ningning Xie authored

AntC authored
as per comments on the ticket; also linked to Haskell folk art of 'Smart constructors'.

Ben Gamari authored

Alec Theriault authored

David Sanders authored

Michael Sloan authored

jhb563 authored

Sasa Bogicevic authored

Ö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

 11 Jul, 2018 4 commits


Ryan Scott authored
Summary: 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, prettyprinting an `IfaceAppTy` now goes through the `IfaceAppArgs` prettyprinter, 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 authored
c.f. Trac #14873

Simon Peyton Jones authored

Richard Eisenberg authored
The removed line could cause GHC to hang by printing a knottied type.

 10 Jul, 2018 10 commits


Richard Eisenberg authored
This addresses #14808 [ci skip]

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 authored
Previously, we kindchecked 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: indexedtypes/should_compile/T15142.hs

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 checker.) 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 authored
This is a documentationonly fix, addressing Trac #15354.

Simon Peyton Jones authored
This was a tricky one. During type checking we maintain TcType: Note [The wellkinded type invariant] That is, types are wellkinded /without/ zonking. But in tcInferApps we were destroying that invariant by calling substTy, which in turn uses smart constructors, which eliminate apparentlyredundant 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 authored
And I added some HasDebugCallStack constraints to tcExpectedKind and related functions too.

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 oneline tcHsTypeApp fix in too because it just seems more consistent.

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 TcValidity.checkValidInstHead 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 authored
Summary: 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

 08 Jul, 2018 1 commit


Ryan Scott authored
Summary: I needed this when debugging #15346. Test Plan: Does it compile? It does? Cool. Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15311 Differential Revision: https://phabricator.haskell.org/D4944

 06 Jul, 2018 11 commits


Ben Gamari authored
This reverts commit 87367158. I hadn't intended on merging this.

Ben Gamari authored
Previously we would prevent any operating system not providing the MEM_NORESERVE flag from using the twostep allocator. Afterall, Linux will reserve swapspace for a mapping unless this flag is given, which is most certainly not what we want. However, it seems that FreeBSD provides the reservationonly mapping behavior that we expect despite not providing the MEM_NORESERVE macro. In fact, it provided the macro until 2014, when it was removed on account of not being implemented in the kernel. However, empirical evidence suggests that just plain mmap does what we want. Reviewers: erikd, simonmar Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #15348 Differential Revision: https://phabricator.haskell.org/D4939

Ben Gamari authored
Reviewers: Phyx Reviewed By: Phyx Subscribers: Phyx, rwbarton, thomie, carter GHC Trac Issues: #15053 Differential Revision: https://phabricator.haskell.org/D4883

Sylvain Henry authored
The recent patch "Builtin Natural literals in Core" (https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6 585ef) introduced a regression when desugaring large numbers. This patch fixes it and adds a regression test. Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15301 Differential Revision: https://phabricator.haskell.org/D4885

Matthew Pickering authored
The logic for `DFunUnfolding` seemed quite confusing and unecessary. A simpler strategy uses `maybeUnfoldingTemplate`, as that is what is actually used when doing inlining and checking that has the right type. Reviewers: simonpj, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4919

Michael Sloan authored
The stderr output is ``` Loading with T9693_initial.hs T9693_main.hs:4:1: Same exact name in multiple namespaces: type constructor or class ‘X’, declared at: T9693_main.hs:4:1 data constructor ‘X’, declared at: T9693_main.hs:4:1 Probable cause: you bound a unique Template Haskell name (NameU), perhaps via newName, in different namespaces. If that's it, then ddumpsplices might be useful Reloading with T9693_modified.hs T9693_main.hs:1:1: Data constructor ‘X’ used as a type constructor ``` The strange thing is that the modified version uses (mkName "X"), which should be fine for simultaneous use in both a data constructor and type constructor. Indeed, on a fresh load, the modified version works fine. So there is some sort of state left over from the prior load when (newName "X") was used. Test Plan: testsuite/tests/th/T9693.script Reviewers: bgamari, sighingnow, RyanGlScott Reviewed By: sighingnow, RyanGlScott Subscribers: RyanGlScott, sighingnow, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4926

Krzysztof Gogolewski authored
Test Plan: validate Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15342 Differential Revision: https://phabricator.haskell.org/D4933

Ben Gamari authored
Reviewers: mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4898

Ben Gamari authored
Test Plan: Try `./validate`, CircleCI build; make sure core count detection works in both cases. Reviewers: alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14470 Differential Revision: https://phabricator.haskell.org/D4897

Krzysztof Gogolewski authored

Ryan Scott authored
Summary: I discovered when debugging #15346 that the Core Lint error message for ill typed casts always mentions types of enclosed //expressions//, even if the thing being casted is actually a type. This generalizes `mkCastErr` a bit to allow it to give the proper labelling for kind coercions. Test Plan: Run on failing program in #15346, read the Core Lint error Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4940

 05 Jul, 2018 1 commit


Ryan Scott authored
The stdout produced by test tcrun045 changed in commit 45f44e2c. The change appears to be benign, so I've decided to accept it.
