 02 Mar, 2018 4 commits


Ryan Scott authored
Within `pprDataFamInstDecl`, we were invoking `pprFamInstLHS` to prettyprint a data family instance header, and we were passing `Just` a kind signature to `pprFamInstLHS` to make it prettyprint the kind signature alongside it (this is a consequence of commit d1ef223c). But this is silly, because then invoke `pp_data_defn`, which //also// prettyprints the kind signature, resulting in the kind signature being printed twice by mistake. This fix is simple—pass `Nothing` to `pprFamInstLHS` instead. Test Plan: make test TEST=T14817 Reviewers: alanz, bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, thomie, carter GHC Trac Issues: #14817 Differential Revision: https://phabricator.haskell.org/D4418

Ryan Scott authored
Test Plan: make test TEST=T12790 Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, dfeuer, rwbarton, thomie, carter GHC Trac Issues: #12790 Differential Revision: https://phabricator.haskell.org/D4412

Tao He authored
Previously we didn't do exhaustive checking on MultiIf expressions and guards in pattern bindings. We can construct the `LMatch` directly from GRHSs or [LHsExpr] (MultiIf's alts) then feed it to checkMatches, without construct the MatchGroup and using function `matchWrapper`. Signedoffby: HE, Tao <sighingnow@gmail.com> Test Plan: make test TEST="T14773a T14773b" Reviewers: bgamari, RyanGlScott, simonpj Reviewed By: bgamari, simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14773 Differential Revision: https://phabricator.haskell.org/D4400

niteria authored
Before this change we would compute a hash of all the command line optP flags once per file. With a lot of files and many optP flags, that's a lot of repeated work. I added a new Note that explains the approach and rationale. Test Plan: new test Reviewers: simonmar, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14697 Differential Revision: https://phabricator.haskell.org/D4445

 01 Mar, 2018 1 commit


Ben Gamari authored
This reverts commit d675a354.

 27 Feb, 2018 4 commits


Simon Peyton Jones authored
I'd put the stderr file in my link tree, not in the source tree, so my original push had the wrong file, even though my tree validated. Sorry!

Simon Peyton Jones authored

Simon Peyton Jones authored
I'm not sure why. It's an odd test, mind you; a weird typefunction recursion thing. So I'm not inclined to investigate. Anyway, good!

Simon Peyton Jones authored
The pure unifier was building an infinite type, through a defective occurs check. So GHC went into an infinite loop. Reason: we were neglecting the 'kco' part of the type, which 'unify_ty' maintains. Yikes. The fix is easy. I refactored a bit to make it harder to go wrong in future.

 25 Feb, 2018 1 commit


Ben Gamari authored

 20 Feb, 2018 1 commit


Ben Gamari authored
Sadly it's not immediately obvious where this regression came from: * T5837 started failing on OS X with 0c2350c2 * It's not clear when T1969 started failing due to the recent out of memory issues on Harbormaster

 18 Feb, 2018 5 commits


Ryan Scott authored
Previously, we were extracting the free variables from a GADT constructor in an incorrect order, which caused the type variables for the constructor's type signature to end up in nontoposorted order. Thankfully, rearranging the order of types during renaming makes swift work of this bug. This fixes a regression introduced in commit fa29df02. For whatever reason, that commit also commented out a significant portion of the `T13123` test. This code appears to work, so I've opted to uncomment it. Test Plan: make test TEST=T14808 Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14808 Differential Revision: https://phabricator.haskell.org/D4413

Tao He authored
Print different error message for improper UNPACK and strictness annotations. Fix Trac #14761. Signedoffby: HE, Tao <sighingnow@gmail.com> Test Plan: make test TEST="T7210 T14761a T14761b" Reviewers: goldfire, bgamari, RyanGlScott, simonpj Reviewed By: RyanGlScott, simonpj Subscribers: simonpj, goldfire, rwbarton, thomie, carter GHC Trac Issues: #14761 Differential Revision: https://phabricator.haskell.org/D4397

Douglas Wilson authored
Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4389

Matthías Páll Gissurarson authored
This adds valid refinement substitution suggestions for typed holes and documentation thereof. Inspired by Agda's refinement facilities, this extends the typed holes feature to be able to search for valid refinement substitutions, which are substitutions that have one or more holes in them. When the flag `frefinementlevelsubstitutions=n` where `n > 0` is passed, we also look for valid refinement substitutions, i.e. substitutions that are valid, but adds more holes. Consider the following: f :: [Integer] > Integer f = _ Here the valid substitutions suggested will be (with the new `funcluttervalidsubstitutions` flag for less verbosity set): ``` Valid substitutions include f :: [Integer] > Integer product :: forall (t :: * > *). Foldable t => forall a. Num a => t a > a sum :: forall (t :: * > *). Foldable t => forall a. Num a => t a > a maximum :: forall (t :: * > *). Foldable t => forall a. Ord a => t a > a minimum :: forall (t :: * > *). Foldable t => forall a. Ord a => t a > a head :: forall a. [a] > a (Some substitutions suppressed; use fmaxvalidsubstitutions=N or fnomaxvalidsubstitutions) ``` When the `frefinementlevelsubstitutions=1` flag is given, we additionally compute and report valid refinement substitutions: ``` Valid refinement substitutions include foldl1 _ :: forall (t :: * > *). Foldable t => forall a. (a > a > a) > t a > a foldr1 _ :: forall (t :: * > *). Foldable t => forall a. (a > a > a) > t a > a head _ :: forall a. [a] > a last _ :: forall a. [a] > a error _ :: forall (a :: TYPE r). GHC.Stack.Types.HasCallStack => [Char] > a errorWithoutStackTrace _ :: forall (a :: TYPE r). [Char] > a (Some refinement substitutions suppressed; use fmaxrefinementsubstitutions=N or fnomaxrefinementsubstitutions) ``` Which are substitutions with holes in them. This allows e.g. beginners to discover the fold functions and similar. We find these refinement suggestions by considering substitutions that don't fit the type of the hole, but ones that would fit if given an additional argument. We do this by creating a new type variable with newOpenFlexiTyVarTy (e.g. `t_a1/m[tau:1]`), and then considering substitutions of the type `t_a1/m[tau:1] > v` where `v` is the type of the hole. Since the simplifier is free to unify this new type variable with any type (and it is cloned before each check to avoid sideeffects), we can now discover any identifiers that would fit if given another identifier of a suitable type. This is then generalized so that we can consider any number of additional arguments by setting the `frefinementlevelsubstitutions` flag to any number, and then considering substitutions like e.g. `foldl _ _` with two additional arguments. This can e.g. help beginners discover the `fold` functions. This could also help more advanced users figure out which morphisms they can use when arrow chasing. Then you could write `m = _ . m2 . m3` where `m2` and `m3` are some morphisms, and not only get exact fits, but also help in finding morphisms that might get you a little bit closer to where you want to go in the diagram. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4357

Ryan Scott authored
It turns out that one can produce illformed Core by combining `GeneralizedNewtypeDeriving`, `TypeInType`, and `TypeFamilies`, as demonstrated in #14728. The root of the problem is allowing the last parameter of a class to appear in a //kind// of an associated type family, as our current approach to deriving associated type family instances simply doesn't work well for that situation. Although it might be possible to properly implement this feature today (see https://ghc.haskell.org/trac/ghc/ticket/14728#comment:3 for a sketch of how this might work), there does not currently exist a performant implementation of the algorithm needed to accomplish this. Until such an implementation surfaces, we will make this corner case of `GeneralizedNewtypeDeriving` an error. Test Plan: make test TEST="T14728a T14728b" Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14728 Differential Revision: https://phabricator.haskell.org/D4402

 16 Feb, 2018 1 commit


Ryan Scott authored
Previously, we were skipping over `$tcUnit#` entirely when wiring in `Typeable` tycons, resulting in #14811. Easily fixed. Test Plan: make test TEST=T14811 Reviewers: bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, rwbarton, thomie, carter GHC Trac Issues: #14811 Differential Revision: https://phabricator.haskell.org/D4414

 13 Feb, 2018 3 commits


Tao He authored
Empty GADTs data declarations can't be identified in type checker. This patch adds additional checks in parser and raise a parse error when encounter empty GADTs declarations but extension `GADTs` is not enabled. Only empty declarations are checked in parser to avoid affecting existing error messages related to missing GADTs extension. This patch should fix issue 8258. Signedoffby: HE, Tao <sighingnow@gmail.com> Test Plan: make test TEST="T8258 T8258NoGADTs" Reviewers: bgamari, mpickering, alanz, RyanGlScott Reviewed By: bgamari, RyanGlScott Subscribers: adamse, RyanGlScott, rwbarton, thomie, mpickering, carter GHC Trac Issues: #8258 Differential Revision: https://phabricator.haskell.org/D4350

Ben Gamari authored

Ömer Sinan Ağacan authored
This patch includes two changes: 1. Move cost centre collection from `SCCfinal` to `CorePrep`, to be able to collect cost centres in unfoldings. `CorePrep` drops unfoldings, so that's the latest stage in the compilation pipeline for this. After this change `SCCfinal` no longer collects all cost centres, but it still generates & collects CAF cost centres + updates cost centre stacks of `StgRhsClosure` and `StgRhsCon`s. This fixes #5889. 2. Initialize cost centre stack fields of `StgRhs` in `coreToStg`. With this we no longer need to update cost centre stack fields in `SCCfinal`, so that module is removed. Cost centre initialization explained in Note [Costcentre initialization plan]. Because with fcafall we need to attach a new costcentre to each CAF, `coreTopBindToStg` now returns `CollectedCCs`. Test Plan: validate Reviewers: simonpj, bgamari, simonmar Reviewed By: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #5889 Differential Revision: https://phabricator.haskell.org/D4325

 08 Feb, 2018 1 commit


Simon Peyton Jones authored
When finishing up an implication constraint, it's a bit tricky to decide which Derived constraints to retain (for error reporting) and which to discard. I got this wrong in commit f20cf982 (Remove wc_insol from WantedConstraints) The particular problem in Trac #14763 was that we were reporting as an error a fundepgenerated constraint (ex ~ T) where 'ex' is an existentiallybound variable in a pattern match. But this isn't really an error at all. This patch fixes the problem. Indeed, since I had to understand this rather tricky code, I took the opportunity to clean it up and document better. See isDroppableCt :: Ct > Bool and Note [Dropping derived constraints] I also removed wl_deriv altogether from the WorkList data type. It was there in the hope of gaining efficiency by not even processing lots of derived constraints, but it has turned out that most derived constraints (notably equalities) must be processed anyway; see Note [Prioritise equalities] in TcSMonad. The two are coupled because to decide which constraints to put in wl_deriv I was using another variant of isDroppableCt. Now it's much simpler  and perhaps even more efficient too.

 07 Feb, 2018 1 commit


Simon Peyton Jones authored
This patch fixes the redundant superclass expansion in Trac #14774. The main change is to fix TcInterac.solveOneFromTheOther, so that it does not prefer a workitem with a binding if that binding transitively depends on the inert item we are comparing it with. Explained in Note [Replacement vs keeping] in TcInert, esp item (c) of the "Constraints coming from the same level" part. To make this work I refactored out a new function TcEvidence.findNeededEvVars, which was previously buried inside TcSimplify.neededEvVars. I added quite a few more comments and signposts about superclass expansion.

 06 Feb, 2018 3 commits


Ben Gamari authored

Edward Z. Yang authored
See comment in Packages for more details. Fixes #14717. Signedoffby: Edward Z. Yang <ezyang@fb.com> Test Plan: validate Reviewers: snoyberg, taylorfausak, bgamari Reviewed By: snoyberg, taylorfausak, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14717 Differential Revision: https://phabricator.haskell.org/D4376

Ben Gamari authored

 04 Feb, 2018 1 commit


Ben Gamari authored

 03 Feb, 2018 1 commit


Ryan Scott authored
Commit 193664d4 added a special caseRule for `dataToTag`, but this transformation completely broke when `dataToTag` was applied to somewith with a type headed by a data family, leading to #14680. For now at least, the simplest solution is to simply not apply this transformation when the type is headed by a data family. Test Plan: make test TEST=T14680 Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14680 Differential Revision: https://phabricator.haskell.org/D4371

 02 Feb, 2018 2 commits


David Feuer authored
Reviewers: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4340

Ben Gamari authored
CircleCI seems to suggest that the cost center ordering is wrong in the prof way. I'm beginning to wonder whether there is some nondeterminism here. If only I know what this test was supposed to be testing.

 01 Feb, 2018 10 commits


Simon Peyton Jones authored
This allows you to see the output immediately after desugaring but before any optimisation. I've wanted this for some time, but I was triggered into action by Trac #13032 comment:9. Interestingly, the change means that with dcorelint we will now Lint the output before the very simple optimiser; and this showed up Trac #14749. But that's not the fault of ddumpdspreopt!

Simon Peyton Jones authored
There's a 6% reduction in allocation on T3064. I think it's due to commit e4ab65bd Author: Tobias Dammers <tdammers@gmail.com> Date: Wed Jan 31 21:39:45 2018 0500 Optimize coercionKind (Trac #11735) I'm not certain  but, hey, it's good news

Tao He authored
Fixes #14740. Test Plan: make test TEST="14740" Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14740 Differential Revision: https://phabricator.haskell.org/D4359

Andreas Klebinger authored
This prevents the register being picked up as a scratch register. Otherwise the allocator would be free to use it before a call. This fixes #14619. Test Plan: ci, repro case on #14619 Reviewers: bgamari, Phyx, erikd, simonmar, RyanGlScott, simonpj Reviewed By: Phyx, RyanGlScott, simonpj Subscribers: simonpj, RyanGlScott, Phyx, rwbarton, thomie, carter GHC Trac Issues: #14619 Differential Revision: https://phabricator.haskell.org/D4348

Ryan Scott authored
Currently, any standalonederived instance must satisfy the property that the tycon of the data type having an instance being derived for it must be either a normal ADT tycon or a data family tycon. But there are several other primitive tycons—such as `(>)`, `Int#`, and others—which cannot have standalonederived instances (via the `anyclass` strategy) as a result of this check! See https://ghc.haskell.org/trac/ghc/ticket/13154#comment:8 for an example of where this overly conservative restriction bites. Really, this validity check only makes sense in the context of `stock` deriving, where we need the property that the tycon is that of a normal ADT or a data family in order to inspect its data constructors. Other deriving strategies don't require this validity check, so the most sensible way to fix this error is to move the logic of this check into `cond_stdOK`, which is specific to `stock` deriving. This makes progress towards fixing (but does not entirely fix) Test Plan: make test TEST=T13154a Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13154 Differential Revision: https://phabricator.haskell.org/D4337

takanoakio authored
This patch implements the BlockArguments extension, as proposed at https://github.com/ghcproposals/ghcproposals/pull/90. It also fixes #10855 as a sideeffect. This patch adds a large number of shiftreduce conflicts to the parser. All of them concern the ambiguity as to where constructs like `if` and `let` end. Fortunately they are resolved correctly by preferring shift. The patch is based on @gibiansky's ArgumentDo implementation (D1219). Test Plan: ./validate Reviewers: goldfire, bgamari, alanz, mpickering Reviewed By: bgamari, mpickering Subscribers: Wizek, dfeuer, gibiansky, rwbarton, thomie, mpickering, carter GHC Trac Issues: #10843, #10855 Differential Revision: https://phabricator.haskell.org/D4260

Julian Priestley authored
When using the :add command in haxlsh/ghci, a module/file that can't be found is still added to the list of targets, resulting in an error message for the bad module/file for every subsequent usage of the command. The add command should verify that the module/file can be found before adding it to the list of targets. Also add a ":show targets" command to show the currently added list of commands, and an ":unadd" command to remove a target. Test Plan: Add a new GHCi testcase that checks that :add doesn't remember either files or modules that could not be found, and that both the new :show and :unadd commands work as expected. Reviewers: simonmar, bgamari Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14676 Differential Revision: https://phabricator.haskell.org/D4321

blaze authored
Currently runtime keeps hold to 4*used_memory. This includes, in particular, nursery, which can be quite large on multiprocessor machines: 16 CPUs x 64Mb each is 1GB. Multiplying it by 4 means whatever actual memory usage is, runtime will never release memory under 4GB, and this is quite excessive for processes which only need a lot of memory shortly (think building data structures from large files). This diff makes multiplier to apply only to GCmanaged memory, leaving all "static" allocations alone. Test Plan: make test TEST="T14702" Reviewers: bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14702 Differential Revision: https://phabricator.haskell.org/D4338

Ben Gamari authored
Looks right to me.

Ben Gamari authored
Arguably the warning should just be disabled for this test to eliminate unnecessary wiggle in the future.

 31 Jan, 2018 1 commit


Ben Gamari authored
These two tests have been failing on CircleCI.
