summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't use a generic apply thunk for known callsSebastian Graf2018-12-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, an AP thunk like `sat = f a b c` will not have its own entry point and info pointer and will instead reuse a generic apply thunk like `stg_ap_4_upd`. That's great from a code size perspective, but if `f` is a known function, a specialised entry point with a plain call can be much faster than figuring out the arity and doing dynamic dispatch. This looks at `f`s arity to figure out if it is a known function and if so, it will not lower it to a generic apply function. Benchmark results are encouraging: No changes to allocation, but 0.2% less counted instructions. Test Plan: Validates locally Reviewers: simonmar, osa1, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #16005 Differential Revision: https://phabricator.haskell.org/D5414
* Remove a tcTraceSimon Peyton Jones2018-12-061-1/+2
| | | | | | This tcTrace, in tcTyFamInstEqn, caused a knot-tying loop, because it was printing a type after zonking-to-Type. Easy solution: don't do that.
* Remove duplicates in -ddump-minimial-importsSimon Peyton Jones2018-12-051-17/+25
| | | | | | | | | | | | | | | | | | | | | This fixes Trac #15994. Previously RdrName.gresToAvailInfo assumed that the input list of GREs had no duplicates. I accidentally broke this precondition in this refactoring: commit 6353efc7694ba8ec86c091918e02595662169ae2 Date: Thu Nov 22 14:48:05 2018 -0500 Fix unused-import warnings This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely (There was an ASSERT, but it's usually switched off in stage2. It tripped when I switched stage2 assertions on.) The fix is straightforward: account for dups in gresToAvailInfo.
* Fix link name to a noteArnaud Spiwack2018-12-031-1/+1
| | | | | | | | | | Reviewers: goldfire, bgamari, tdammers Reviewed By: tdammers Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5399
* Comments onlySimon Peyton Jones2018-12-032-5/+22
|
* Introduce tcTypeKind, and use itSimon Peyton Jones2018-12-0327-313/+304
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the type checker Constraint and * are distinct; and the function that takes the kind of a type should respect that distinction (Trac #15971). This patch implements the change: * Introduce Type.tcTypeKind, and use it throughout the type inference engine * Add new Note [Kinding rules for types] for the kinding rules, especially for foralls. * Redefine isPredTy ty = tcIsConstraintKind (tcTypeKind ty) (it had a much more complicated definition before) Some miscellaneous refactoring * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp, in favour of TyCoRep.kindRep, kindRep_maybe * Rename Type.getRuntimeRepFromKind_maybe to getRuntimeRep_maybe I did some spot-checks on compiler perf, and it really doesn't budge (as expected).
* Fix #15954 by rejigging check_type's orderRyan Scott2018-12-033-19/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, `check_type` (which catches illegal uses of unsaturated type synonyms without enabling `LiberalTypeSynonyms`, among other things) always checks for uses of polytypes before anything else. There is a problem with this plan, however: checking for polytypes requires decomposing `forall`s and other invisible arguments, an action which itself expands type synonyms! Therefore, if we have something like: ```lang=haskell type A a = Int type B (a :: Type -> Type) = forall x. x -> x type C = B A ``` Then when checking `B A`, `A` will get expanded to `forall x. x -> x` before `check_type` has an opportunity to realize that `A` is an unsaturated type synonym! This is the root cause of #15954. This patch fixes the issue by moving the case of `check_type` that detects polytypes to be //after// the case that checks for `TyConApp`s. That way, the `TyConApp` case will properly flag things like the unsaturated use of `A` in the example above before we ever attempt to check for polytypes. Test Plan: make test TEST=T15954 Reviewers: simonpj, bgamari, goldfire Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15954 Differential Revision: https://phabricator.haskell.org/D5402
* Warn on all out-of-range literals in pats/exprsAlec Theriault2018-12-036-96/+189
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These changes were motivated by #13256. While poking around, I realized we weren't very consistent in our "-Woverflowed-literals" warnings. This patch fixes that by: * warning earlier on in the pipeline (ie. before we've desugared 'Int' patterns into 'I# Int#') * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed literals) * covering more pattern / expression forms 4/6 of the warnings in the 'Overflow' test are due to this patch. The other two are mostly for completeness. Also fixed a missing empty-enumeration warning for 'Natural'. This warnings were tripped up by the 'Bounded Word' instance (see #9505), but the fix was obvious and simple: use unboxed word literals. Test Plan: make TEST=Overflow && make TEST=T10930 Reviewers: hvr, bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #13256, #10930 Differential Revision: https://phabricator.haskell.org/D5181
* Deduplicate decision to count thunks in `-ticky`Sebastian Graf2018-11-301-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, the logic that checks whether a thunk has a counter or not was duplicated in multiple functions. This led to thunk enters being accounted to their enclosing functions in `StgCmmTicky.tickyEnterThunk`, because the outer call to `withNewTickyCounterThunk` didn't set the counter label for the thunk. And rightly so! `tickyEnterThunk` should only account thunk enters to a counter if `-ticky-dyn-thunk` is on. This patch extracts the logic that was already present in its most general form in `withNewTickyCounterThunk` into its own functions and lets all other call sites checking for `-ticky-dyn-thunk` call this new function named `thunkHasCounter` instead. Reviewers: bgamari, simonmar Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5392
* Fix #15953 by consistently using dumpIfSet_dyn to print debug outputChaitanya Koparkar2018-11-299-51/+70
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In some modules we directly dump the debugging output to STDOUT via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file` is enabled, that output should be written to a file. Easily fixed. Certain tests (T3017, Roles3, T12763 etc.) expect part of the output generated by `-ddump-types` to be in 'PprUser' style. However, generally we want all other debugging output to use 'PprDump' style. `traceTcRn` and `traceTcRnForUser` help us accomplish this. This patch also documents some missing flags in the users guide. Reviewers: RyanGlScott, bgamari, hvr Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15953 Differential Revision: https://phabricator.haskell.org/D5382
* Fix #15828, from `More explicit foralls`Matthew Yacavone2018-11-291-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fix a bug in commit 12eeb9 which permits the following: ``` class C a where type T a b instance C (Maybe a) where type forall a b. T (Maybe a) b = b ``` where instead, the user should write: ``` instance C (Maybe a) where type forall b. T (Maybe a) b = b ``` Update the users guide to discuss scoping of type variables in explicit foralls in type family instances. Test Plan: validate Reviewers: bgamari, goldfire, monoidal Reviewed By: goldfire Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15828 Differential Revision: https://phabricator.haskell.org/D5283
* Taming the Kind Inference MonsterSimon Peyton Jones2018-11-2951-2790/+3169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881
* Comments onlySimon Peyton Jones2018-11-282-19/+23
|
* Add Note [Dead case binders in -O0]Sebastian Graf2018-11-281-1/+13
| | | | | | | | | | | | | | | After reverting Phab:D5358, Simon (Peyton Jones) asked for a Note summarising why we want to keep the dead case binder check in `cgCase`. Summary from mail conversation: * Phab:D5324 means that we no longer /recompute/ dead-ness of case-binders in STG-land * But TidyPgm preserves dead-ness info (see CoreTidy.tidyIdBndr) * And so we can take advantage of it to avoid a redundant load. This load would be eliminated by CmmSink, but that only happens with -O
* Fix #15941 by only special-casing visible infix applicationsRyan Scott2018-11-261-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The iface pretty-printer had a special case for an application of an infix type constructor to two arguments. But this didn't take the visibilities of the arguments into account, which could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when `-fprint-explicit-kinds` was enabled (#15941). The fix is relatively straightforward: simply plumb through the visibilities of each argument, and only trigger the special case for infix applications if both arguments are visible (i.e., required). Test Plan: make test TEST=T15941 Reviewers: goldfire, bgamari, monoidal Reviewed By: goldfire, monoidal Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15941 Differential Revision: https://phabricator.haskell.org/D5375
* Print explicit foralls in type family eqns when appropriateRyan Scott2018-11-263-25/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When `-fprint-explicit-foralls` is enabled, type family equations are either printed without an explict `forall` entirely, or with a bizarre square bracket syntax (in the case of closed type families). I find neither satisfying, so in this patch, I introduce support for printing explicit `forall`s in open type-family, closed type-family, and data-family equations when appropriate. (By "when appropriate", I refer to the conditions laid out in `Note [When to print foralls]` in `IfaceType`.) One tricky point in the implementation is that I had to pick a visibility for each type variable in a `CoAxiom`/`FamInst` in order to be able to pass it to `pprUserIfaceForAll` //et al.// Because the type variables in a type family instance equation can't be instantiated by the programmer anyway, the choice only really matters for pretty-printing purposes, so I simply went with good ol' trustworthy `Specified`. (This design choice is documented in `Note [Printing foralls in type family instances]` in `IfaceType`.) Test Plan: make test TEST=T15827 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15827 Differential Revision: https://phabricator.haskell.org/D5282
* Fix build on darwinÖmer Sinan Ağacan2018-11-261-1/+1
| | | | CPP error introduced with b2950e0
* Revert "Remove redundant check in cgCase"Ömer Sinan Ağacan2018-11-261-4/+7
| | | | | | This reverts commit d13b7d60650cb84af11ee15b3f51c3511548cfdb. (See discussion in D5358)
* [TTG: Handling Source Locations] Foundation and PatShayan-Najd2018-11-2454-1930/+2454
| | | | | | | | | | | | | | | | | | This patch removes the ping-pong style from HsPat (only, for now), using the plan laid out at https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations (solution A). - the class `HasSrcSpan`, and its functions (e.g., `cL` and `dL`), are introduced - some instances of `HasSrcSpan` are introduced - some constructors `L` are replaced with `cL` - some patterns `L` are replaced with `dL->L` view pattern - some type annotation are necessarily updated (e.g., `Pat p` --> `Pat (GhcPass p)`) Phab diff: D5036 Trac Issues #15495 Updates haddock submodule
* Fix unused import warning=2018-11-241-1/+0
| | | | Presumably introduced by new unused import checker.
* Revert "'DynFlag'-free version of 'mkParserFlags'"Ben Gamari2018-11-233-83/+55
| | | | This reverts commit 5aa29231ab7603537284eff5e4caff3a73dba6d2.
* Revert "Simplify 'ExtBits' in the lexer"Ben Gamari2018-11-233-238/+306
| | | | This reverts commit d2fbc33c4ff3074126ab71654af8bbf8a46e4e11.
* Implement late lambda liftSebastian Graf2018-11-2320-140/+1512
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This implements a selective lambda-lifting pass late in the STG pipeline. Lambda lifting has the effect of avoiding closure allocation at the cost of having to make former free vars available at call sites, possibly enlarging closures surrounding call sites in turn. We identify beneficial cases by means of an analysis that estimates closure growth. There's a Wiki page at https://ghc.haskell.org/trac/ghc/wiki/LateLamLift. Reviewers: simonpj, bgamari, simonmar Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #9476 Differential Revision: https://phabricator.haskell.org/D5224
* Fix unused-import warningsDavid Eichmann2018-11-2257-209/+242
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely commit 9376249b6b78610db055a10d05f6592d6bbbea2f Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Wed Oct 28 17:16:55 2015 +0000 Fix unused-import stuff in a better way In that patch got the sense of the comparison back to front, and thereby failed to implement the unused-import rules described in Note [Choosing the best import declaration] in RdrName This led to Trac #13064 and #15393 Fixing this bug revealed a bunch of unused imports in libraries; the ones in the GHC repo are part of this commit. The two important changes are * Fix the bug in bestImport * Modified the rules by adding (a) in Note [Choosing the best import declaration] in RdrName Reason: the previosu rules made Trac #5211 go bad again. And the new rule (a) makes sense to me. In unravalling this I also ended up doing a few other things * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the things that are used, rather than [AvailInfo]. This is simpler and more direct. * Rename greParentName to greParent_maybe, to follow GHC naming conventions * Delete dead code RdrName.greUsedRdrName Bumps a few submodules. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27 Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5312
* Don't pass -no-pie when -pgmc is suppliedKrzysztof Gogolewski2018-11-221-1/+4
| | | | | | | | | | | | | | Test Plan: validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15319 Differential Revision: https://phabricator.haskell.org/D5317
* Simplify 'ExtBits' in the lexerAlec Theriault2018-11-223-306/+238
| | | | | | | | | | | | | | | | | | The main change is to export 'ExtBits' instead of defining/exporting a bunch of boilerplate functions that test for a particular 'ExtBits'. In the process, I also * cleaned up an unneeded special case for 'ITstatic' * made 'UsePosPrags' another variant of 'ExtBits' * made the logic in 'reservedSymsFM' match that of 'reservedWordsFM' Test Plan: make test Reviewers: bgamari, alanz Subscribers: sjakobi, rwbarton, mpickering, carter Differential Revision: https://phabricator.haskell.org/D5332
* 'DynFlag'-free version of 'mkParserFlags'Alec Theriault2018-11-223-55/+83
| | | | | | | | | | | | | | | | | | | | | | | | | Obtaining a `DynFlags` is difficult, making using the lexer/parser for pure parsing/lexing unreasonably difficult, even with `mkPStatePure`. This is despite the fact that we only really need * language extension flags * warning flags * a handful of boolean options The new `mkParserFlags'` function makes is easier to directly construct a `ParserFlags`. Furthermore, since `pExtsBitmap` is just a footgun, I've gone ahead and made `ParserFlags` an abstract type. Reviewers: bgamari, alanz, sjakobi Reviewed By: bgamari, sjakobi Subscribers: mpickering, sjakobi, rwbarton, carter GHC Trac Issues: #11301 Differential Revision: https://phabricator.haskell.org/D5269
* LLVM: Use generic code for small size quot-rem opsPeter Trommler2018-11-221-2/+2
|
* llvmGen: Eliminate duplicate definitionGabor Greif2018-11-222-3/+2
| | | | remove local
* UNREG: PprC: Add support for adjacent floatsJames Clarke2018-11-221-1/+23
| | | | | | | | | | | | | | | | When two 32-bit floats are adjacent for a 64-bit target, there is no padding between them to force alignment, so we must combine their bit representations into a single word. Reviewers: bgamari, simonmar Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15853 Differential Revision: https://phabricator.haskell.org/D5306
* Overhaul -fprint-explicit-kinds to use VKARyan Scott2018-11-2212-185/+316
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the behavior of `-fprint-explicit-kinds` so that it displays kind argument using visible kind application. In other words, the flag now: 1. Prints instantiations of specified variables with `@(...)`. 2. Prints instantiations of inferred variables with `@{...}`. In addition, this patch removes the `Use -fprint-explicit-kinds to see the kind arguments` error message that often arises when a type mismatch occurs due to different kinds. Instead, whenever there is a kind mismatch, we now enable the `-fprint-explicit-kinds` flag locally to help cue to the programmer where the error lies. (See `Note [Kind arguments in error messages]` in `TcErrors`.) As a result, these funny `@{...}` things can now appear to the user even without turning on the `-fprint-explicit-kinds` flag explicitly, so I took the liberty of documenting them in the users' guide. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15871 Differential Revision: https://phabricator.haskell.org/D5314
* Remove warnings-silencing flags for code generated by AlexSimon Jakobi2018-11-222-52/+9
| | | | | | | | | | | | | | | | | | Current versions of Alex don't seem to produce as many warnings any more. In order to silence a warning and to avoid overlong lines, I've taken the liberty of refactoring 'tok_num'. Test Plan: ./validate Reviewers: bgamari, simonmar Reviewed By: simonmar Subscribers: erikd, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5319
* Calling gcc: Pass optc flags as last options (#14452)Roland Senn2018-11-221-1/+3
| | | | | | | | | | | | | | Test Plan: make test TEST=T14452 Reviewers: hvr, bgamari, monoidal, thomie, osa1 Reviewed By: osa1 Subscribers: rwbarton, carter GHC Trac Issues: #14452 Differential Revision: https://phabricator.haskell.org/D5318
* Fix #15852 by eta expanding data family instance RHSes, tooRyan Scott2018-11-227-38/+83
| | | | | | | | | | | | | | | | | | | | | | When I defined `etaExpandFamInstLHS`, I blatantly forgot to eta expand the RHSes of data family instances. (Actually, I claimed that they didn't //need// to be eta expanded. I'm not sure what I was thinking.) This fixes the issue by changing `etaExpandFamInstLHS` to `etaExpandFamInst` and, well, making it actually eta expand the RHS. Test Plan: make test TEST=T15852 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15852 Differential Revision: https://phabricator.haskell.org/D5328
* Refactor TcRnMonad.mapAndRecoverMSimon Jakobi2018-11-222-1/+6
| | | | | | | | | | | | | | | This version doesn't require the 'reverse' step after the monadic fold. Test Plan: ./validate Reviewers: bgamari, tdammers Reviewed By: tdammers Subscribers: monoidal, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5343
* Fix deadlock bug when mkFastStringWith is duplicatedZejun Wu2018-11-222-3/+5
| | | | | | | | | | | | | | | | | | | | In D5211, we use `withMVar` to guard writes to the same segment, this is unsafe to be duplicated. It can lead to deadlock if it is only run partially and `putMVar` is not called after `takeMVar`. Test Plan: ./validate We used to see deadlock when building stackage without this fix, and it no longer happens. Reviewers: simonmar, bgamari Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5349
* Don't reverse explicit export lists during renamingSimon Jakobi2018-11-222-24/+33
| | | | | | | | | | | | | | | | | This will be useful for Hi Haddock / D5067. Previously any export list in 'tcg_rn_exports' would be in reverse order. Also remove a redundant setSrcSpan. Test Plan: ./validate Reviewers: bgamari Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5347
* Fixup the new code layout patch for SplitObjs.klebinger.andreas@gmx.at2018-11-221-3/+7
| | | | | | | | | | | | | | | When splitting objects we sometimes generate dummy CmmProcs containing bottom in some fields. Code introduced in the new code layout patch looked at these which blew up the compiler. Now we instead check first if the function actually contains code. Reviewers: bgamari Subscribers: simonpj, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5357
* Rename literal constructorsSylvain Henry2018-11-2238-424/+439
| | | | | | | | | | | | | | | | | | | | | | | | In a previous patch we replaced some built-in literal constructors (MachInt, MachWord, etc.) with a single LitNumber constructor. In this patch we replace the `Mach` prefix of the remaining constructors with `Lit` for consistency (e.g., LitChar, LitLabel, etc.). Sadly the name `LitString` was already taken for a kind of FastString and it would become misleading to have both `LitStr` (literal constructor renamed after `MachStr`) and `LitString` (FastString variant). Hence this patch renames the FastString variant `PtrString` (which is more accurate) and the literal string constructor now uses the least surprising `LitString` name. Both `Literal` and `LitString/PtrString` have recently seen breaking changes so doing this kind of renaming now shouldn't harm much. Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27, tdammers Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4881
* Minor performance optimisationGabor Greif2018-11-221-5/+5
| | | | only concat once
* another minor refactoringGabor Greif2018-11-221-4/+4
|
* Remove redundant check in cgCaseÖmer Sinan Ağacan2018-11-201-7/+4
| | | | | | | | | | | | | D5339 (part of D5324) removed the dead case binder analysis done during CoreToStg so this condition always holds now. Test Plan: Validated locally. Reviewers: sgraf, bgamari, simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5358
* Don't track free variables in STG syntax by defaultSebastian Graf2018-11-1915-372/+404
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, `CoreToStg` annotates `StgRhsClosure`s with their set of non-global free variables. This free variable information is only needed in the final code generation step (i.e. `StgCmm.codeGen`), which leads to transformations such as `StgCse` and `StgUnarise` having to maintain this information. This is tiresome and unnecessary, so this patch introduces a trees-to-grow-like approach that only introduces the free variable set into the syntax tree in the code gen pass, along with a free variable analysis on STG terms to generate that information. Fixes #15754. Reviewers: simonpj, osa1, bgamari, simonmar Reviewed By: osa1 Subscribers: rwbarton, carter GHC Trac Issues: #15754 Differential Revision: https://phabricator.haskell.org/D5324
* Fix typo in docsChris Done2018-11-181-1/+1
| | | I've been reading this line of docs for years and it ruffles my feathers.
* Introduce Int16# and Word16#Abhiroop Sarkar2018-11-1712-69/+269
| | | | | | | | | | | | This builds off of D4475. Bumps binary submodule. Reviewers: carter, AndreasK, hvr, goldfire, bgamari, simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D5006
* Fix trac #15702, as a followon to fix for #13704.Chris Smith2018-11-171-2/+4
| | | | | | | | | | | | | | | | | | Summary: The effect of this change is that -main-is changes the default export list for the main module, but does not apply the same change to non-main modules. This fixes some cases where -main-is was used to wrap a module that expected that default behavior (exporting `main`, even when that wasn't the main entry point name). Reviewers: mpickering, monoidal, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #13704, #15702 Differential Revision: https://phabricator.haskell.org/D5322
* Minor refactoringGabor Greif2018-11-171-13/+13
| | | | PR: https://github.com/ghc/ghc/pull/223/
* More compact Outputable instance for `Uniq(D)Set`Sebastian Graf2018-11-172-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Until now, `UniqSet` and `UniqDSet` inherited their `Outputable` instances from `UniqFM` and `UniqDFM`. That made for verbose and redundant output. This patch rectifies that by pretty-printing these sets in common math notation. E.g., previously, we would render `UniqSet`s like this: [s2fE :-> x_s2fE, s2fF :-> y_s2fF, s2fG :-> z_s2fG, s2fH :-> g_s2fH] Now, they're are printed like this: {x_s2fE, y_s2fF, z_s2fG, g_s2fH} Reviewers: simonpj, bgamari, AndreasK, dfeuer, osa1 Reviewed By: osa1 Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15879 Differential Revision: https://phabricator.haskell.org/D5315
* Speed up MonadUtils.mapMaybeMSimon Jakobi2018-11-171-5/+4
| | | | | | | | | | | | Summary: This version is nearly 2x faster according to a few small benchmarks. Reviewers: bgamari, monoidal Reviewed By: monoidal Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5344
* Fix #12906: GHC fails to typecheck Main module without mainRoland Senn2018-11-171-5/+5
| | | | | | | | | | | | | | | | | | Summary: The function fail is no longer called immediately after adding the no-main error message to the TcM monad. The rest of the module will be typechecked. Test Plan: make test TEST=T12906 Reviewers: dfeuer, RyanGlScott, ezyang, mpickering, bgamari Reviewed By: RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #12906 Differential Revision: https://phabricator.haskell.org/D5338
View Lorry Controller Status