- Apr 17, 2018
-
-
Ben Gamari authored
-
Ben Gamari authored
-
Ben Gamari authored
-
- Apr 16, 2018
-
-
Ben Gamari authored
-
- Apr 14, 2018
-
-
Simon Peyton Jones authored
This commit: commit fb050a33 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Thu Oct 12 11:00:19 2017 +0100 Do not bind coercion variables in SpecConstr rules arranged to reject any SpecConstr call pattern that mentioned a coercion in the pattern. There was a good reason for that -- see Note [SpecConstr and casts] -- but I didn't realise how important it was to accept patterns that mention casts in /terms/. Trac #14936 showed this up. This patch just narrows the restriction to discard only the cases where the coercion is mentioned only in types. Fortunately that was pretty easy to do. (cherry picked from commit 5ab8094e)
-
as helpfully outlined by SPJ. This commit copies a small bit code from `SetLevels` which could reasonably be put in `Id` as `zapAllIdinfo`; I did not do this to make merging this commmit into `ghc-8.4` easier. If this commit gets merged, then presumably after commit 3f59d380 (test case) and ae0cff0a (other fixes to Exitify.hs). Differential Revision: https://phabricator.haskell.org/D4582 (cherry picked from commit 3cfb12d8)
-
this succeeds on `master` right now, but I confirmed that it fails on ghc-8.4.1-release. (cherry picked from commit 3f59d380)
-
As the CSE transformation traverses the syntax tree, it needs to go past the lambdas of a join point, and only look for CSE opportunities inside, as a join point’s lambdas must be preserved. Simple fix; comes with a Note and a test case. Thanks to Ryan Scott for an excellently minimized test case, and for bisecting GHC. Differential Revision: https://phabricator.haskell.org/D4572 (cherry picked from commit ae0cff0a)
-
Ryan Scott authored
Summary: In D4113, a `FixIOException` data type was added with a `@since TODO` annotation, but it seems that `TODO` made it out into `base-4.11` itself. I've (retroactively) fixed this and added an entry to the `base-4.11` entry in the `changelog`. Test Plan: Read it Reviewers: dfeuer, hvr, bgamari Reviewed By: dfeuer Subscribers: thomie, carter GHC Trac Issues: #14356, #15025 Differential Revision: https://phabricator.haskell.org/D4578 (cherry picked from commit ce27c7d5)
-
- Apr 13, 2018
-
-
Ben Gamari authored
Reviewers: hvr, bgamari Subscribers: lelf, thomie, carter Differential Revision: https://phabricator.haskell.org/D4575 (cherry picked from commit 4b831c27)
-
Ryan Scott authored
This takes care of bumping the `base` and `integer-gmp` minor version numbers in anticipation of a GHC 8.4.2 release. While I was in town, I also filled in a `@since TODO` Haddock annotation for `powModSecInteger` in `integer-gmp` with `1.0.2.0`, and updated the changelog accordingly. Test Plan: ./validate Reviewers: hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15025 Differential Revision: https://phabricator.haskell.org/D4586 (cherry picked from commit c4814ab6)
-
Ryan Scott authored
Previously, GHC was quite eager to panic whenever it was fed an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an explicit error message instead, so this patch accomplishes just that. Test Plan: make test TEST=T14708 Reviewers: Phyx, hvr, bgamari Reviewed By: Phyx Subscribers: thomie, carter GHC Trac Issues: #9438, #14708, #15032 Differential Revision: https://phabricator.haskell.org/D4589 (cherry picked from commit 7613a812)
-
- Apr 11, 2018
-
-
push() considers BLOCKING_QUEUES to be an invalid closure type which should never be present on the stack. However, retainClosure made no accomodation for this and ended up pushing such a closure. This lead to #14947. Test Plan: Validate Reviewers: simonmar, erikd Reviewed By: simonmar Subscribers: thomie, carter, RyanGlScott GHC Trac Issues: #14947 Differential Revision: https://phabricator.haskell.org/D4538 (cherry picked from commit d5f6d7a0)
-
- Mar 29, 2018
-
-
Ben Gamari authored
-
Ryan Scott authored
Previously, GHC allowed all of the following: ```lang=haskell data Foo1 :: Constraint data family Foo2 :: Constraint data family Foo3 :: k data instance Foo3 :: Constraint ``` Yikes! This is because GHC was confusing `Type` with `Constraint` due to careless use of the `isLiftedTypeKind` function. To respect this distinction, I swapped `isLiftedTypeKind` out for `tcIsStarKind`—which does respect this distinction—in the right places. Test Plan: make test TEST="T14048a T14048b T14048c" Reviewers: bgamari Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, carter GHC Trac Issues: #14048 Differential Revision: https://phabricator.haskell.org/D4479 (cherry picked from commit f748c529)
-
Simon Peyton Jones authored
This patch fixes an outright bug in tcDataKindSig, shown up in Trac of a data type declaration. See Note [TyConBinders for the result kind signature of a data type] I also took the opportunity to elminate the DataKindCheck argument and data type from tcDataKindSig, instead moving the check to the call site, which is easier to understand. (cherry picked from commit 68149452)
-
Ömer Sinan Ağacan authored
This reverts commit 59d7ee53 and enables the test for #14052. (See #14052 for the discussion) Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14052 Differential Revision: https://phabricator.haskell.org/D4478 (cherry picked from commit 98c7749c)
-
- Mar 28, 2018
-
-
The backslash currently in this type signature makes no sense. Without it, the example is fine. (cherry picked from commit 960cd424)
-
Ben Gamari authored
-
Ben Gamari authored
-
Ben Gamari authored
-
- Mar 26, 2018
-
-
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. (cherry picked from commit e99fdf77)
-
Ryan Scott authored
The way GHC was handling `DeriveAnyClass` was subtly wrong in two notable ways: * In `inferConstraintsDAC`, we were //always// bumping the `TcLevel` of newly created unification variables, under the assumption that we would always place those unification variables inside an implication constraint. But #14932 showed precisely the scenario where we had `DeriveAnyClass` //without// any of the generated constraints being used inside an implication, which made GHC incorrectly believe the unification variables were untouchable. * Even worse, we were using the generated unification variables from `inferConstraintsDAC` in every single iteration of `simplifyDeriv`. In #14933, however, we have a scenario where we fill in a unification variable with a skolem in one iteration, discard it, proceed on to another iteration, use the same unification variable (still filled in with the old skolem), and try to unify it with a //new// skolem! This results in an utter disaster. The root of both these problems is `inferConstraintsDAC`. This patch fixes the issue by no longer generating unification variables directly in `inferConstraintsDAC`. Instead, we store the original variables from a generic default type signature in `to_metas`, a new field of `ThetaOrigin`, and in each iteration of `simplifyDeriv`, we generate fresh meta tyvars (avoiding the second issue). Moreover, this allows us to more carefully fine-tune the `TcLevel` under which we create these meta tyvars, fixing the first issue. Test Plan: make test TEST="T14932 T14933" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14932, #14933 Differential Revision: https://phabricator.haskell.org/D4507 (cherry picked from commit 98930426)
-
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 (cherry picked from commit ced9fbd3)
-
Ryan Scott authored
For some reason, `axSub0R` was left out of `typeNatCoAxiomRules` in `TcTypeNats`, which led to disaster when trying to look up `Sub0R` from an interface file, as demonstrated in #14934. The fix is simple—just add `axSub0R` to that list. To help prevent an issue like this happening in the future, I added a `Note [Adding built-in type families]` to `TcTypeNats`, which contains a walkthrough of all the definitions in `TcTypeNats` you need to update when adding a new built-in type family. Test Plan: make test TEST=T14934 Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14934 Differential Revision: https://phabricator.haskell.org/D4508 (cherry picked from commit c3aea396)
-
Simon Peyton Jones authored
This subtle patch fixes Trac #5129 (again; comment:20 and following). I took the opportunity to document seq# properly; see Note [seq# magic] in PrelRules, and Note [seq# and expr_ok] in CoreUtils. (cherry picked from commit abaf43d9)
-
Simon Peyton Jones authored
The RULE for bitInteger was trying to constant-fold bitInteger 9223372036854775807# which meant constructing a gigantic Integer at compile time. Very bad idea! Easily fixed. Fixes Trac #14959, #14962. (cherry picked from commit efc844f5)
-
Ömer Sinan Ağacan authored
When interpreter is not profiled (see `interpreterProfiled` in `DynFlags`) bytecode generator generates a NULL pointer as the cost centre of a `BRK_FUN` instruction: let cc | interpreterProfiled dflags = cc_arr ! tick_no | otherwise = toRemotePtr nullPtr let breakInstr = BRK_FUN (fromIntegral tick_no) (getUnique this_mod) cc return $ breakInstr `consOL` code We now take this into account when disassembling `BRK_FUN`. Reviewers: bgamari, simonmar, erikd Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4490 (cherry picked from commit 8e341013)
-
Ömer Sinan Ağacan authored
Given this program: main = do f $ do a <- return 3 c <- do return 5 GHC previously gave this error message: Main.hs:2:7: error: Parse error in pattern: do a <- return 3 c Possibly caused by a missing 'do'? | 2 | f $ do | ^^... What happened is GHC considered the whole `f $ do a <- return 3 c` as a pattern. When parsed as an expression it becomes an infix application of `($)`, and GHC checks left and right hand sides before checking if `($)` is a valid infix constructor name, and shows the first error it got. If instead we first check if the infix op is valid in pattern context, the error message becomes much clearer: Main.hs:2:3: error: Parse error in pattern: f $ do a <- return 3 c Possibly caused by a missing 'do'? | 2 | f $ do | ^^^^^^... This may not entirely fix #11188 but I think it's an improvement. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11188 Differential Revision: https://phabricator.haskell.org/D4497 (cherry picked from commit cb6d8589)
-
Test Plan: `make test TEST=T14925` Reviewers: hvr, dfeuer Reviewed By: dfeuer Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14925 Differential Revision: https://phabricator.haskell.org/D4530 (cherry picked from commit 20ae19fc)
-
Ryan Scott authored
Manually-written instances and standalone-derived instances have the benefit of having the `checkValidInstHead` function run over them, which catches manual instances of built-in types like `(~)` and `Coercible`. However, instances generated from `deriving` clauses weren't being passed through `checkValidInstHead`, leading to confusing results as in #14916. `checkValidInstHead` also has additional validity checks for language extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up until now, GHC has never required these language extensions for `deriving` clause, so to avoid unnecessary breakage, I opted to suppress these language extension checks for `deriving` clauses, just like we currently suppress them for `SPECIALIZE instance` pragmas. Test Plan: make test TEST=T14916 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14916 Differential Revision: https://phabricator.haskell.org/D4501 (cherry picked from commit 20f14b4f)
-
-g1 removes block information, but it turns out that procs can refer to block information through parents. Note [Splitting DebugBlocks] explains the parentage relationship. Test Plan: * ./validate * added a new test Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14894 Differential Revision: https://phabricator.haskell.org/D4496 (cherry picked from commit 0cbb13b3)
-
- Mar 25, 2018
-
-
Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4491 (cherry picked from commit d718023e)
-
Ryan Scott authored
Summary: In commit dbd81f7e, a regression was inadvertently introduced which caused derived `Read` instances for record data types with fields ending in a `#` symbol (using `MagicHash`) would no longer parse on valid output. This is ultimately due to the same reasons as #5041, as we cannot parse a field name like `foo#` as a single identifier. We fix this issue by employing the same workaround as in #5041: first parse the identifier name `foo`, then then symbol `#`. This is accomplished by the new `readFieldHash` function in `GHC.Read`. This will likely warrant a `base-4.11.1.0` release. Test Plan: make test TEST=T14918 Reviewers: tdammers, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14918 Differential Revision: https://phabricator.haskell.org/D4502 (cherry picked from commit d5577f44)
-
Reviewers: hvr Subscribers: rwbarton, thomie, erikd, carter Differential Revision: https://phabricator.haskell.org/D4483 (cherry picked from commit a25b763f)
-
Summary: OpenIndiana apparently reports a triple of i386-pc-solaris2.11. Reviewers: hvr Subscribers: rwbarton, thomie, erikd, carter Differential Revision: https://phabricator.haskell.org/D4487 (cherry picked from commit 4fa077a2a1d6e6e7a45ef03a1075ff3c7dddb23d)
-
- Mar 08, 2018
-
-
Ben Gamari authored
OpenIndiana apparently reports a triple of i386-pc-solaris2.11.
-
Ben Gamari authored
-
Ben Gamari authored
Thanks to Gabor for pointing this out.
-
- Mar 06, 2018
-
-
This was broken by D3746 and/or D3809, but unfortunately we didn't notice because CI at the time wasn't building the profiling way. Test Plan: ``` cd testsuite/test/profiling/should_run make WAY=ghci-ext-prof ``` Reviewers: bgamari, michalt, hvr, erikd Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14705 Differential Revision: https://phabricator.haskell.org/D4437 (cherry picked from commit 488d63d6)
-