summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add test for #14880wip/T14880-2-step3Tobias Dammers2018-09-172-0/+14
|
* Fix #14880.Richard Eisenberg2018-09-144-20/+83
| | | | | | | This fix is described in Note [Removing variables with bound kinds] in TcType. This commit also changes split_dvs to close over kinds at the end, which seems more performant than walking over the kind of every tyvar occurrence.
* Add Note [Closing over free variable kinds]Tobias Dammers2018-09-131-1/+78
|
* Close over kinds exactly once per var (#14880)Tobias Dammers2018-09-131-9/+13
| | | | | | | | | | | | | | | | | | | | | Summary: As discussed in Trac:14880, comment:123, we have the issue that we want to avoid processing the same var more than once. The original plan was to move closing over kinds to the very end of the `tyCoVarsOfType` function, however, this turns out to be inefficient and unnecessary. Instead, we simply change the code in `ty_co_vars_of_type` such that closing over kinds doesn't happen if we've already seen the var in question. Test Plan: ./validate, nofib Reviewers: simonpj, goldfire, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #14880 Differential Revision: https://phabricator.haskell.org/D5147
* BugfixTobias Dammers2018-09-101-1/+1
|
* Use an accumulator version of tyCoVarsOfTypeSimon Peyton Jones2018-09-101-96/+283
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is part 1 from #14880: factor out a worker for the tyCoVarsOf... family of function, implementing them in terms of VarSet, but with accumulator-style (like in `FV`) built in, and with the same kind of pre-insert lookup; this has shown to perform better than either FV or plain VarSet in this particular scenario. Original notes from simonpj: In TyCoRep we now have tyCoVarsOfType implemented 1) Using FV -- this is the baseline version in GHC today 2) Using VarSets via unionVarSet 3) Using VarSets in accumulator-style In this patch (3) is enabled. When compiling perf/compiler/T5631 we get Compiler allocs (1) 1,144M (2) 1,175M (3) 1,142M The key new insight in (3) is this: ty_co_vars_of_type (TyVarTy v) is acc | v `elemVarSet` is = acc | v `elemVarSet` acc = acc <---- NB! | otherwise = ty_co_vars_of_type (tyVarKind v) is (extendVarSet acc v) Notice the second line! If the variable is already in the accumulator, don't re-add it. This makes big difference. Without it, allocation is 1,169M or so. One cause is that we only take the free vars of its kind once; that problem will go away when we do the main part of #14088 and close over kinds /afterwards/. But still, another cause is perhaps that every insert into a set overwrites the previous item, and so allocates a new path to the item; it's not a no-op even if the item is there already. Why use (3) rather than (1)? Becuase it just /has/ to be better; * FV carries around an InterestingVarFun, which does nothing useful here, but is tested at every variable * FV carries around a [Var] for the deterministic version. For this very hot operation (finding free vars) I think it makes sense to have speical purpose code. On the way I also simplified the (less used) coVarsOfType/Co family to use FV, by making serious use of the InterestingVarFun! Test Plan: validate, nofib Reviewers: simonpj, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #14880 Differential Revision: https://phabricator.haskell.org/D5141
* Avoid creating unevaluated Int thunks when iterating in GHC.ForeignNeil Mitchell2018-09-081-4/+4
|
* Refactor Foreign.Marshal modules for more modern styleÖmer Sinan Ağacan2018-09-082-62/+29
| | | | | | | | | | | | (use ScopedTypeVariables to remove dummy arguments) Reviewers: bgamari, RyanGlScott, dfeuer, hvr, monoidal Reviewed By: monoidal Subscribers: monoidal, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5124
* users-guide: Disable syntax highlightingTakenobu Tani2018-09-071-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ghc: Remove warning of StaticPointers not being supported by GHCiBen Gamari2018-09-072-13/+3
| | | | | Support for StaticPointers was added in #12356 but I apparently neglected to remove the warning.
* Documentation tweaksKrzysztof Gogolewski2018-09-071-18/+7
| | | | | | | | | | | | | | | | | | | 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 (d66d409bf6) - Fix link in pattern signatures Test Plan: build Reviewers: bgamari, takenobu Reviewed By: takenobu Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5132
* Various RTS bug fixes:Ömer Sinan Ağacan2018-09-072-3/+2
| | | | | | | | | | | | | | | | | - Retainer profiler: init_srt_thunk() should mark the stack entry as SRT - Retainer profiler: Remove an incorrect assertion about FUN_STATIC. FUN_STATIC does not have to have an SRT. - Fix nptrs of BCO Test Plan: validate Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5134
* Fix a race between GC threads in concurrent scavengingÖmer Sinan Ağacan2018-09-062-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While debugging #15285 I realized that free block lists (free_list in BlockAlloc.c) get corrupted when multiple scavenge threads allocate and release blocks concurrently. Here's a picture of one such race: Thread 2 (Thread 32573.32601): #0 check_tail (bd=0x940d40 <stg_TSO_info>) at rts/sm/BlockAlloc.c:860 #1 0x0000000000928ef7 in checkFreeListSanity () at rts/sm/BlockAlloc.c:896 #2 0x0000000000928979 in freeGroup (p=0x7e998ce02880) at rts/sm/BlockAlloc.c:721 #3 0x0000000000928a17 in freeChain (bd=0x7e998ce02880) at rts/sm/BlockAlloc.c:738 #4 0x0000000000926911 in freeChain_sync (bd=0x7e998ce02880) at rts/sm/GCUtils.c:80 #5 0x0000000000934720 in scavenge_capability_mut_lists (cap=0x1acae80) at rts/sm/Scav.c:1665 #6 0x000000000092b411 in gcWorkerThread (cap=0x1acae80) at rts/sm/GC.c:1157 #7 0x000000000090be9a in yieldCapability (pCap=0x7f9994e69e20, task=0x7e9984000b70, gcAllowed=true) at rts/Capability.c:861 #8 0x0000000000906120 in scheduleYield (pcap=0x7f9994e69e50, task=0x7e9984000b70) at rts/Schedule.c:673 #9 0x0000000000905500 in schedule (initialCapability=0x1acae80, task=0x7e9984000b70) at rts/Schedule.c:293 #10 0x0000000000908d4f in scheduleWorker (cap=0x1acae80, task=0x7e9984000b70) at rts/Schedule.c:2554 #11 0x000000000091a30a in workerStart (task=0x7e9984000b70) at rts/Task.c:444 #12 0x00007f99937fa6db in start_thread (arg=0x7f9994e6a700) at pthread_create.c:463 #13 0x000061654d59f88f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 32573.32573): #0 checkFreeListSanity () at rts/sm/BlockAlloc.c:887 #1 0x0000000000928979 in freeGroup (p=0x7e998d303540) at rts/sm/BlockAlloc.c:721 #2 0x0000000000926f23 in todo_block_full (size=513, ws=0x1aa8ce0) at rts/sm/GCUtils.c:264 #3 0x00000000009583b9 in alloc_for_copy (size=513, gen_no=0) at rts/sm/Evac.c:80 #4 0x000000000095850d in copy_tag_nolock (p=0x7e998c675f28, info=0x421d98 <Main_Large_con_info>, src=0x7e998d075d80, size=513, gen_no=0, tag=1) at rts/sm/Evac.c:153 #5 0x0000000000959177 in evacuate (p=0x7e998c675f28) at rts/sm/Evac.c:715 #6 0x0000000000932388 in scavenge_small_bitmap (p=0x7e998c675f28, size=1, bitmap=0) at rts/sm/Scav.c:271 #7 0x0000000000934aaf in scavenge_stack (p=0x7e998c675f28, stack_end=0x7e998c676000) at rts/sm/Scav.c:1908 #8 0x0000000000934295 in scavenge_one (p=0x7e998c66e000) at rts/sm/Scav.c:1466 #9 0x0000000000934662 in scavenge_mutable_list (bd=0x7e998d300440, gen=0x1b1d880) at rts/sm/Scav.c:1643 #10 0x0000000000934700 in scavenge_capability_mut_lists (cap=0x1aaa340) at rts/sm/Scav.c:1664 #11 0x00000000009299b6 in GarbageCollect (collect_gen=0, do_heap_census=false, gc_type=2, cap=0x1aaa340, idle_cap=0x1b38aa0) at rts/sm/GC.c:378 #12 0x0000000000907a4a in scheduleDoGC (pcap=0x7ffdec5b5310, task=0x1b36650, force_major=false) at rts/Schedule.c:1798 #13 0x0000000000905de7 in schedule (initialCapability=0x1aaa340, task=0x1b36650) at rts/Schedule.c:546 #14 0x0000000000908bc4 in scheduleWaitThread (tso=0x7e998c0067c8, ret=0x0, pcap=0x7ffdec5b5430) at rts/Schedule.c:2537 #15 0x000000000091b5a0 in rts_evalLazyIO (cap=0x7ffdec5b5430, p=0x9c11f0, ret=0x0) at rts/RtsAPI.c:530 #16 0x000000000091ca56 in hs_main (argc=1, argv=0x7ffdec5b5628, main_closure=0x9c11f0, rts_config=...) at rts/RtsMain.c:72 #17 0x0000000000421ea0 in main () In particular, dbl_link_onto() which is used to add a freed block to a doubly-linked free list is not thread safe and corrupts the list when called concurrently. Note that thread 1 is to blame here as thread 2 is properly taking the spinlock. With this patch we now take the spinlock when freeing a todo block in GC, avoiding this race. Test Plan: - Tried slow validate locally: this patch does not introduce new failures. - circleci: https://circleci.com/gh/ghc/ghc-diffs/283 The test got killed because it took 5 hours but T7919 (which was previously failing on circleci) passed. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15285 Differential Revision: https://phabricator.haskell.org/D5115
* Remove an incorrect assertion in threadPaused:Ömer Sinan Ağacan2018-09-061-7/+0
| | | | | | | | | | | | | | | | The assertion is triggered when we have a loop in the program (in which case we see the same update frame multiple times in the stack). See #14915 for more details. Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #14915 Differential Revision: https://phabricator.haskell.org/D5133
* Preserve specialisations despite CSESimon Peyton Jones2018-09-057-15/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #15445 showed that, as a result of CSE, a function with an automatically generated specialisation RULE could be inlined before the RULE had a chance to fire. This patch attaches a NOINLINE[2] activation to the Id, during CSE, to stop this happening. See Note [Delay inlining after CSE] ---- Historical note --- This patch is simpler and more direct than an earlier version: commit 2110738b280543698407924a16ac92b6d804dc36 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Mon Jul 30 13:43:56 2018 +0100 Don't inline functions with RULES too early We had to revert this patch because it made GHC itself slower. Why? It delayed inlining of /all/ functions with RULES, and that was very bad in TcFlatten.flatten_ty_con_app * It delayed inlining of liftM * That delayed the unravelling of the recursion in some dictionary bindings. * That delayed some eta expansion, leaving flatten_ty_con_app = \x y. let <stuff> in \z. blah * That allowed the float-out pass to put sguff between the \y and \z. * And that permanently stopped eta expasion of the function, even once <stuff> was simplified. -- End of historical note ---
* Define activeAfterInitial, activeDuringFinalSimon Peyton Jones2018-09-054-9/+19
| | | | | | | This is pure refactoring, just adding a couple of definitions to BasicTypes, and using them. Plus some whitespace stuff.
* Expose 'moduleToPkgConfAll' from 'PackageState'Alec Theriault2018-09-051-1/+1
| | | | | | | | | | | | | | | Summary: Having direct access to this field is going to enable Haddock to compute in batch which modules to load before looking up instances of external packages. Reviewers: bgamari, monoidal Reviewed By: monoidal Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5100
* testsuite: Use bools for booleans, not intsBen Gamari2018-09-053-29/+29
| | | | | | | | | | | | | | Summary: Just as it says on the tin. Test Plan: Validate Reviewers: bgamari, osa1 Reviewed By: osa1 Subscribers: osa1, monoidal, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D5010
* base: Add references to Notes for certain special importsChaitanya Koparkar2018-09-056-9/+11
| | | | | | | | | | | | | | | | | | | Summary: Modules like GHC.Integer, GHC.Natural etc. are special and sometimes have to be imported just to resolve build ordering issues. It's useful to refer to the appropriate Notes at such import sites. Test Plan: Read it. Reviewers: RyanGlScott, bgamari, hvr, simonpj Reviewed By: RyanGlScott, simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15526 Differential Revision: https://phabricator.haskell.org/D5092
* testsuite: Add test for #15368Ben Gamari2018-09-053-0/+57
| | | | | | | | | | | | Reviewers: bgamari, osa1 Reviewed By: osa1 Subscribers: osa1, monoidal, rwbarton, thomie, carter GHC Trac Issues: #15368 Differential Revision: https://phabricator.haskell.org/D4958
* Skip eventlog tests in GHCi wayÖmer Sinan Ağacan2018-09-051-2/+2
| | | | | | | | | | | | | | | | | | Summary: (GHCi doesn't generate event logs) Test Plan: These tests were failing in GHCi way, they're now skipped in GHCi way as GHCi doesn't generate eventlogs Reviewers: bgamari, simonmar, maoe, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, carter GHC Trac Issues: #15587 Differential Revision: https://phabricator.haskell.org/D5119
* Fix tests ghci057 and T9293. (#15071)roland2018-09-042-8/+0
| | | | | | | | | | | | | | | | | Summary: As both tests specify -fno-ghci-leak-check, the GHCi :set command is not expected to list the -fghci-leak check flag. Test Plan: WINDOWS: make test TESTS="ghci057 T9293" Reviewers: bgamari, monoidal Reviewed By: monoidal Subscribers: rwbarton, carter GHC Trac Issues: #15071 Differential Revision: https://phabricator.haskell.org/D5125
* testsuite: make CHECK_API_ANNOTATIONS and CHECK_PPR overridableAlp Mestanogullari2018-09-041-1/+7
| | | | | | | | | | | | | | | | | | | | Summary: Without this patch, boilerplate.mk (which is included by a lot of Makefiles from our testsuite) just assumes they reside in the usual inplace directory, which is not friendly to hadrian and this makes a lot of tests (e.g T10255) fail when building GHC and running the testsuite with hadrian. With this patch, the said tests pass. Test Plan: api annotation tests (with hadrian) Reviewers: bgamari, monoidal Reviewed By: monoidal Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5127
* Add a test for Trac #15586Krzysztof Gogolewski2018-09-042-0/+13
| | | | | | | | | | | | | | | | Summary: The bug is already fixed in master. Test Plan: make test TEST=T15586 Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15586 Differential Revision: https://phabricator.haskell.org/D5118
* Compiler panic on invalid syntax (unterminated pragma)roland2018-09-043-7/+22
| | | | | | | | | | | | | | | | Summary: After a parse error in OPTIONS_GHC issue an error message instead of a compiler panic. Test Plan: make test TEST=T15053 Reviewers: Phyx, thomie, bgamari, monoidal, osa1 Reviewed By: Phyx, monoidal, osa1 Subscribers: tdammers, osa1, rwbarton, carter GHC Trac Issues: #15053 Differential Revision: https://phabricator.haskell.org/D5093
* Fix typos in -Wsimplifiable-class-constraints flag docsSergey Vinokurov2018-09-041-2/+2
|
* Remove duplicate "since" field in glasgow_exts.rstJosh Price2018-09-031-2/+0
|
* canCFunEqCan: use isTcReflexiveCo (not isTcReflCo)Simon Peyton Jones2018-09-034-4/+109
| | | | | | | | | As Trac #15577 showed, it was possible for a /homo-kinded/ constraint to trigger the /hetero-kinded/ branch of canCFunEqCan, and that triggered an infinite loop. The fix is easier, but there remains a deeper questions: why is the flattener producing giant refexive coercions?
* make iToBase62's inner loop stricter in one of its argumentsAlp Mestanogullari2018-09-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: hadrian's support for dynamic ways is currently broken (see hadrian#641 [1]). The stage 1 GHCs that hadrian produces end up producing bad code for the `iToBase62` function after a few optimisation passes. In the case where `quotRem` returns (overflowError, 0), GHC isn't careful enough to realise q is _|_ and happily inlines, distributes and floats code around until we end up trying to access index `minBound :: Int` of an array of 62 chars, as a result of inlining the definition of `quotRem` for Ints, in particular the minBound branch [2]. I will separately look into reproducing the bad transformation on a small self-contained example and filling a ticket. [1]: https://github.com/snowleopard/hadrian/issues/641 [2]: https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/GHC/Real.hs#l366 Test Plan: fixes hadrian#641 Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: tdammers, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5106
* Reject class instances with type families in kindsRyan Scott2018-09-0210-38/+101
| | | | | | | | | | | | | | | | | | | | | Summary: GHC doesn't know how to handle type families that appear in class instances. Unfortunately, GHC didn't reject instances where type families appear in //kinds//, leading to #15515. This is easily rectified by calling `checkValidTypePat` on all arguments to a class in an instance (and not just the type arguments). Test Plan: make test TEST=T15515 Reviewers: bgamari, goldfire, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15515 Differential Revision: https://phabricator.haskell.org/D5068
* Remove knot-tying bug in TcHsSyn.zonkTyVarOccSimon Peyton Jones2018-08-3114-137/+321
| | | | | | | | | | | | | | | | | | | | | | | | | | There was a subtle knot-tying bug in TcHsSyn.zonkTyVarOcc, revealed in Trac #15552. I fixed it by * Eliminating the short-circuiting optimisation in zonkTyVarOcc, instead adding a finite map to get sharing of zonked unification variables. See Note [Sharing when zonking to Type] in TcHsSyn * On the way I /added/ the short-circuiting optimisation to TcMType.zonkTcTyVar, which has no such problem. This turned out (based on non-systematic measurements) to be a modest win. See Note [Sharing in zonking] in TcMType On the way I renamed some of the functions in TcHsSyn: * Ones ending in "X" (like zonkTcTypeToTypeX) take a ZonkEnv * Ones that do not end in "x" (like zonkTcTypeToType), don't. Instead they whiz up an empty ZonkEnv.
* Commets on flatten_args_tcSimon Peyton Jones2018-08-311-4/+11
|
* Comments onlySimon Peyton Jones2018-08-312-3/+3
|
* Minor improvements to comments [skip ci]Richard Eisenberg2018-08-302-11/+7
|
* fix -ddump-asm descriptionAlp Mestanogullari2018-08-301-1/+1
| | | | | | | | | | | | | | Summary: It was missing some words. Test Plan: None (docs only) Reviewers: bgamari, monoidal Reviewed By: monoidal Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5102
* A few typos [ci skip]Gabor Greif2018-08-303-3/+3
|
* Fix the __GLASGOW_HASKELL__ comparisonKrzysztof Gogolewski2018-08-302-6/+3
| | | | | | | | | | | | | | | | | Summary: GHC 8.4 corresponds to 804, not 840. Found by Gabor Greif. Test Plan: Harbormaster Reviewers: ggreif, bgamari, mpickering Reviewed By: ggreif Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5064
* Finish stable splitDavid Feuer2018-08-2930-344/+586
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Long ago, the stable name table and stable pointer tables were one. Now, they are separate, and have significantly different implementations. I believe the time has come to finish the split that began in #7674. * Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`. * Give each table its own mutex. * Add FFI functions `hs_lock_stable_ptr_table` and `hs_unlock_stable_ptr_table` and document them. These are intended to replace the previously undocumented `hs_lock_stable_tables` and `hs_lock_stable_tables`, which are now documented as deprecated synonyms. * Make `eqStableName#` use pointer equality instead of unnecessarily comparing stable name table indices. Reviewers: simonmar, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15555 Differential Revision: https://phabricator.haskell.org/D5084
* Fix a constant folding ruleAndrey Mokhov2018-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: One of the constant folding rules introduced in D2858 is: ``` (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `add` v) ``` Or, after removing syntactic noise: `(y - v) - (x - w) ==> (y - x) + (w + v)`. This is incorrect, since the sign of `v` is changed from negative to positive. As a consequence, the following program prints `3` when compiled with `-O`: ``` -- This is just subtraction in disguise minus :: Int -> Int -> Int minus x y = (8 - y) - (8 - x) {-# NOINLINE minus #-} main :: IO () main = print (2 `minus` 1) ``` The correct rule is: `(y - v) - (x - w) ==> (y - x) + (w - v)`. This commit does the fix. I haven't found any other issues with the constant folding code, but it's difficult to be certain without some automated checking. Reviewers: bgamari, tdammers Subscribers: hsyl20, tdammers, rwbarton, carter GHC Trac Issues: #15569 Differential Revision: https://phabricator.haskell.org/D5109
* Fixed typo in exponent examplechris-bacon2018-08-291-1/+1
|
* Rename kind vars in left-to-right order in bindHsQTyVarsRyan Scott2018-08-2813-17/+123
| | | | | | | | | | | | | | | | | | | | 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
* Fix typo in 8.6.1 notesKrzysztof Gogolewski2018-08-281-1/+1
|
* Fix #15572 by checking for promoted names in ConTRyan Scott2018-08-284-1/+23
| | | | | | | | | | | | | | | | | | | | | | Summary: When converting `ConT`s to `HsTyVar`s in `Convert`, we were failing to account for the possibility of promoted data constructor names appearing in a `ConT`, which could result in improper pretty-printing results (as observed in #15572). The fix is straightforward: use `Promoted` instead of `NotPromoted` when the name of a `ConT` is a data constructor name. Test Plan: make test TEST=T15572 Reviewers: goldfire, bgamari, simonpj, monoidal Reviewed By: goldfire, simonpj Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15572 Differential Revision: https://phabricator.haskell.org/D5112
* Remove dead code for commandline parsingKrzysztof Gogolewski2018-08-282-16/+1
| | | | | | | | | | | | | | | | Summary: PrefixPred and AnySuffixPred are not used since static flags were removed in bbd3c399939. Test Plan: validate Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5111
* rts: Handle SMALL_MUT_ARR_PTRS in retainer profilterBen Gamari2018-08-281-0/+4
| | | | | | | | | | | | | | Summary: These can be treated similarly to MUT_ARRY_PTRS. Fixes #15529. Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15529 Differential Revision: https://phabricator.haskell.org/D5075
* Remove dph, vector, primitive and random from .gitmodulesChaitanya Koparkar2018-08-271-16/+0
| | | | | | | | | | | | | | Summary: These packages were removed from the GHC source tree in Phab:D4761 and 0905fec089b3270f540c7ee33959cbf8ecfcb4d7. Reviewers: RyanGlScott, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5095
* Bump nofib submoduleKrzysztof Gogolewski2018-08-271-0/+0
|
* Fix #10859 by using foldr1 while deriving Eq instancesChaitanya Koparkar2018-08-271-1/+3
| | | | | | | | | | | | | | | | | | Summary: Previously, we were using foldl1 instead, which led to the derived code to be wrongly associated. Test Plan: ./validate Reviewers: RyanGlScott, nomeata, simonpj, bgamari Reviewed By: RyanGlScott, nomeata Subscribers: rwbarton, carter GHC Trac Issues: #10859 Differential Revision: https://phabricator.haskell.org/D5104
* Don't reify redundant class method tyvars/contextsRyan Scott2018-08-276-18/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, reifying classes produces class methods with redundant tyvars and class contexts in their type signatures, such as in the following: ```lang=haskell class C a where method :: forall a. C a => a ``` Fixing this is very straightforward: just apply `tcSplitMethodTy` to the type of each class method to lop off the redundant parts. It's possible that this could break some TH code in the wild that assumes the existence of these tyvars and class contexts, so I'll advertise this change in the release notes just to be safe. Test Plan: make test TEST="TH_reifyDecl1 T9064 T10891 T14888" Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15551 Differential Revision: https://phabricator.haskell.org/D5088
* Take strict fields into account in coverage checkingRyan Scott2018-08-276-60/+338
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current pattern-match coverage checker implements the formalism presented in the //GADTs Meet Their Match// paper in a fairly faithful matter. However, it was discovered recently that there is a class of unreachable patterns that //GADTs Meet Their Match// does not handle: unreachable code due to strict argument types, as demonstrated in #15305. This patch therefore goes off-script a little and implements an extension to the formalism presented in the paper to handle this case. Essentially, when determining if each constructor can be matched on, GHC checks if its associated term and type constraints are satisfiable. This patch introduces a new form of constraint, `NonVoid(ty)`, and checks if each constructor's strict argument types satisfy `NonVoid`. If any of them do not, then that constructor is deemed uninhabitable, and thus cannot be matched on. For the full story of how this works, see `Note [Extensions to GADTs Meet Their Match]`. Along the way, I did a little bit of much-needed refactoring. In particular, several functions in `Check` were passing a triple of `(ValAbs, ComplexEq, Bag EvVar)` around to represent a constructor and its constraints. Now that we're adding yet another form of constraint to the mix, I thought it appropriate to turn this into a proper data type, which I call `InhabitationCandidate`. Test Plan: make test TEST=T15305 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15305 Differential Revision: https://phabricator.haskell.org/D5087
View Lorry Controller Status