summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Use an accumulator version of tyCoVarsOfTypewip/T14880-2-step1Simon Peyton Jones2018-09-101-96/+283
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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!
* 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
* Fix #15502 by not casting to Int during TH conversionRyan Scott2018-08-274-2/+26
| | | | | | | | | | | | | | | | | | | | | | | Summary: When turning an `IntegerL` to an `IntegralLit` during TH conversion, we were stupidly casting an `Integer` to an `Int` in order to determine how it should be pretty-printed. Unsurprisingly, this causes problems when the `Integer` doesn't lie within the bounds of an `Int`, as demonstrated in #15502. The fix is simple: don't cast to an `Int`. Test Plan: make test TEST=T15502 Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15502 Differential Revision: https://phabricator.haskell.org/D5089
* Fix #15550 by quoting RULE names during TH conversionRyan Scott2018-08-274-2/+22
| | | | | | | | | | | | | | | | | | | Summary: When converting a `RuleP` to a GHC source `RuleD` during TH conversion, we were stupidly not double-quoting the name of the rule. Easily fixed. Test Plan: make test TEST=T15550 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15550 Differential Revision: https://phabricator.haskell.org/D5090
* ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0Tamar Christina2018-08-253-17/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This completes the work started in D4227 by using just 'getExecutablePath' in ghc and ghc-pkg when building with base >= 4.11.0. On the long term, we will be able to simply kill the existing code that follows (or not) symlinks and just get this behaviour for free from getExecutable. For now we however have to require base >= 4.11.0 to be able to just use getExecutablePath under Windows, and use the current code when building with an older base. Original code by @alpmestan commandeering since patch has been stale and bug remains open. Test Plan: Validate Reviewers: angerman, bgamari, erikd, alpmestan Reviewed By: bgamari Subscribers: carter, rwbarton, thomie GHC Trac Issues: #14483 Differential Revision: https://phabricator.haskell.org/D4229
* Better error reporting for inaccessible codeSimon Peyton Jones2018-08-249-30/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes Trac #15558. There turned out to be two distinct problems * In TcExpr.tc_poly_expr_nc we had tc_poly_expr_nc (L loc expr) res_ty = do { traceTc "tcPolyExprNC" (ppr res_ty) ; (wrap, expr') <- tcSkolemiseET GenSigCtxt res_ty $ \ res_ty -> setSrcSpan loc $ -- NB: setSrcSpan *after* skolemising, -- so we get better skolem locations tcExpr expr res_ty Putting the setSrcSpan inside the tcSkolemise means that the location on the Implication constraint is the /call/ to the function rather than the /argument/ to the call, and that is really quite wrong. I don't know what Richard's comment NB means -- I moved the setSrcSpan outside, and the "binding site" info in error messages actually improved. The reason I found this is that it affects the span reported for Trac #15558. * In TcErrors.mkGivenErrorReporter we carefully munge the location for an insoluble Given constraint (Note [Inaccessible code]). But the 'implic' passed in wasn't necesarily the immediately- enclosing implication -- but for location-munging purposes it jolly well should be. Solution: use the innermost implication. This actually simplifies the code -- no need to pass an implication in to mkGivenErrorReporter.
* Add comments about pretty-printing via IfaceSynSimon Peyton Jones2018-08-244-55/+67
| | | | | Provoked by discussion on Phab:D5097 (Trac #15546), I'm adding a big Note explaing the strategy of pretty-printing via IfaceSyn
View Lorry Controller Status