summaryrefslogtreecommitdiff
path: root/compiler/iface
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix #14238 by always pretty-printing visible tyvarsRyan Scott2018-04-071-1/+36
| | | | | | | | | | | | | | | | | | | Summary: Before, GHC would never print visible tyvars in the absence of `-fprint-explicit-foralls`, which led to `:kind` displaying incorrect kinds in GHCi. The fix is simple—simply check beforehand if any of the type variable binders are required when deciding when to pretty-print them. Test Plan: make test TEST=T14238 Reviewers: simonpj, goldfire, bgamari Subscribers: thomie, carter GHC Trac Issues: #14238 Differential Revision: https://phabricator.haskell.org/D4564
* Track type variable scope more carefully.Richard Eisenberg2018-03-312-13/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main job of this commit is to track more accurately the scope of tyvars introduced by user-written foralls. For example, it would be to have something like this: forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool In that type, a's kind must be k, but k isn't in scope. We had a terrible way of doing this before (not worth repeating or describing here, but see the old tcImplicitTKBndrs and friends), but now we have a principled approach: make an Implication when kind-checking a forall. Doing so then hooks into the existing machinery for preventing skolem-escape, performing floating, etc. This also means that we bump the TcLevel whenever going into a forall. The new behavior is done in TcHsType.scopeTyVars, but see also TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant rewriting. There are several Notes near there to guide you. Of particular interest there is that Implication constraints can now have skolems that are out of order; this situation is reported in TcErrors. A major consequence of this is a slightly tweaked process for type- checking type declarations. The new Note [Use SigTvs in kind-checking pass] in TcTyClsDecls lays it out. The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142. Other minor changes: - isUnliftedTypeKind didn't look for tuples and sums. It does now. - check_type used check_arg_type on both sides of an AppTy. But the left side of an AppTy isn't an arg, and this was causing a bad error message. I've changed it to use check_type on the left-hand side. - Some refactoring around when we print (TYPE blah) in error messages. The changes decrease the times when we do so, to good effect. Of course, this is still all controlled by -fprint-explicit-runtime-reps Fixes #14066 #14749 Test cases: dependent/should_compile/{T14066a,T14749}, dependent/should_fail/T14066{,c,d,e,f,g,h}
* Fix #14934 by including axSub0R in typeNatCoAxiomRulesRyan Scott2018-03-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Comments and tiny refactorSimon Peyton Jones2018-03-192-8/+15
| | | | Related to Ryan's upcoming patch for Trac #14933
* Parenthesize (() :: Constraint) in argument positionRyan Scott2018-03-031-7/+8
| | | | | | | | | | | | | | | | | | | Summary: A simple oversight in the pretty-printer lead to a special case for `() :: Constraint` not being parenthesized correctly when used in an argument position. Easily fixed with a `maybeParen`. Test Plan: make test TEST=T14796 Reviewers: alanz, goldfire, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14796 Differential Revision: https://phabricator.haskell.org/D4408
* Cache the fingerprint of sOpt_PBartosz Nitka2018-03-021-1/+36
| | | | | | | | | | | | | | | | | | | | | Before this change we would compute a hash of all the command line -optP flags once per file. With a lot of files and many -optP flags, that's a lot of repeated work. I added a new Note that explains the approach and rationale. Test Plan: new test Reviewers: simonmar, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14697 Differential Revision: https://phabricator.haskell.org/D4445
* Change how includes for input file directory worksTamar Christina2018-02-191-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC Used to only allow for one include mode, namely `-I`. The problem with `-I` includes is that it supercedes all other includes, including the system include paths. This is not a problem for paths requested by the user, but it is a problem for the ones we implicitly derive and add. In particular we add the source directory of the input file to the include path. This is problematic because it causes any file with the name of a system include, to inadvertently loop as the wrong file gets included. Since this is an implicitly include, and as far as I can tell, only done so local includes are found (as the sources given to GCC reside in a temp folder) then switch from `-I` to `-iquote`. This requires a submodule update for haddock Test Plan: ./validate Reviewers: austin, bgamari, hvr Reviewed By: bgamari Subscribers: carter, rwbarton, thomie GHC Trac Issues: #14312 Differential Revision: https://phabricator.haskell.org/D4080
* Typos in commentsGabor Greif2018-01-171-1/+1
|
* Lift constructor tag allocation out of a loopBartosz Nitka2018-01-102-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, for each constructor that we want to allocate a tag for we would traverse a list of all the constructors in a datatype to determine which tag a constructor should get. This is obviously quadratic and for datatypes with 10k constructors it actually makes a big difference. This change implements the plan outlined by @simonpj in https://mail.haskell.org/pipermail/ghc-devs/2017-October/014974.html which is basically about using a map and constructing it outside the loop. One place where things got a bit awkward was TysWiredIn.hs, it would have been possible to just assign the tags by hand, but that seemed error-prone to me, so I decided to go through a map there as well. Test Plan: ./validate On a file with 10k constructors Before: 8,130,522,344 bytes allocated in the heap Total time 3.682s ( 3.920s elapsed) After: 4,133,478,744 bytes allocated in the heap Total time 2.509s ( 2.750s elapsed) Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: goldfire, rwbarton, thomie, simonmar, carter, simonpj GHC Trac Issues: #14657 Differential Revision: https://phabricator.haskell.org/D4289
* Improve pretty-printing for pattern synonymsSimon Peyton Jones2018-01-051-5/+7
| | | | Just better layout in output for the user
* Cache the number of data cons in DataTyCon and SumTyConBartosz Nitka2018-01-041-14/+1
| | | | | | | | | | | | | | | | This is a follow-up after faf60e85 - Make tagForCon non-linear. On the mailing list @simonpj suggested to solve the linear behavior by caching the sizes. Test Plan: ./validate Reviewers: simonpj, simonmar, bgamari, austin Reviewed By: simonpj Subscribers: carter, goldfire, rwbarton, thomie, simonpj Differential Revision: https://phabricator.haskell.org/D4131
* Get evaluated-ness right in the back endSimon Peyton Jones2018-01-031-2/+9
| | | | | | | | | | | | | | | | See Trac #14626, comment:4. We want to maintain evaluted-ness info on Ids into the code generateor for two reasons (see Note [Preserve evaluated-ness in CorePrep] in CorePrep) - DataToTag magic - Potentially using it in the codegen (this is Gabor's current work) But it was all being done very inconsistently, and actually outright wrong -- the DataToTag magic hasn't been working for years. This patch tidies it all up, with Notes to match.
* More informative pretty-printing for phantom coercionsSimon Peyton Jones2018-01-031-2/+15
|
* MkIface: Ensure syntactic compatibility with ghc 8.0.1Ben Gamari2017-12-221-6/+6
| | | | | Prior to 8.0.2 MultiWayIf syntax required that the -> token be indented relative to the guard.
* Refactor coercion holesSimon Peyton Jones2017-12-214-39/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In fixing Trac #14584 I found that it would be /much/ more convenient if a "hole" in a coercion (much like a unification variable in a type) acutally had a CoVar associated with it rather than just a Unique. Then I can ask what the free variables of a coercion is, and get a set of CoVars including those as-yet-un-filled in holes. Once that is done, it makes no sense to stuff coercion holes inside UnivCo. They were there before so we could know the kind and role of a "hole" coercion, but once there is a CoVar we can get that info from the CoVar. So I removed HoleProv from UnivCoProvenance and added HoleCo to Coercion. In summary: * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance * Similarly in IfaceCoercion * Make CoercionHole have a CoVar in it, not a Unique * Make tyCoVarsOfCo return the free coercion-hole variables as well as the ordinary free CoVars. Similarly, remember to zonk the CoVar in a CoercionHole We could go further, and remove CoercionHole as a distinct type altogther, just collapsing it into HoleCo. But I have not done that yet.
* Allow users to ignore optimization changesDavid Feuer2017-12-113-14/+100
| | | | | | | | | | | | | | | | | | | | * Add a new flag, `-fignore-optim-changes`, allowing them to avoid recompilation if the only changes are to the `-O` level or to flags controlling optimizations. * When `-fignore-optim-changes` is *off*, recompile when optimization flags (e.g., `-fno-full-laziness`) change. Previously, we ignored these unconditionally when deciding whether to recompile a module. Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: duog, carter, simonmar, rwbarton, thomie GHC Trac Issues: #13604 Differential Revision: https://phabricator.haskell.org/D4123
* Make use of boot TyThings during typechecking.Edward Z. Yang2017-11-301-20/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Suppose that you are typechecking A.hs, which transitively imports, via B.hs, A.hs-boot. When we poke on B.hs and discover that it has a reference to a type from A, what TyThing should we wire it up with? Clearly, if we have already typechecked A, we should use the most up-to-date TyThing: the one we freshly generated when we typechecked A. But what if we haven't typechecked it yet? For the longest time, GHC adopted the policy that this was *an error condition*; that you MUST NEVER poke on B.hs's reference to a thing defined in A.hs until A.hs has gotten around to checking this. However, actually ensuring this is the case has proven to be a bug farm. The problem was especially poignant with type family consistency checks, which eagerly happen before any typechecking takes place. This patch takes a different strategy: if we ever try to access an entity from A which doesn't exist, we just fall back on the definition of A from the hs-boot file. This means that you may end up with a mix of A.hs and A.hs-boot TyThings during the course of typechecking. Signed-off-by: Edward Z. Yang <ezyang@fb.com> Test Plan: validate Reviewers: simonpj, bgamari, austin, goldfire Subscribers: thomie, rwbarton GHC Trac Issues: #14396 Differential Revision: https://phabricator.haskell.org/D4154
* Change `OPTIONS_GHC -O` to `OPTIONS_GHC -O2`Douglas Wilson2017-11-091-1/+1
| | | | | | | | | | | | | | | These pragmas were having the perverse effect of having these performance critical modules be LESS optimized in builds with -O2. Test Plan: Check on gipedia whether this is worthwhile. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4156
* Invoke lintUnfolding only on top-level unfoldings (#14430)Joachim Breitner2017-11-081-18/+19
| | | | | | | | | | | | as nested unfoldings are linted together with the top-level unfolding, and lintUnfolding does the wrong things for nestd unfoldings that mention join points. The easiest way of doing that was to pass a TopLevel flag through `tcUnfolding`, which is invoked both for top level and nested unfoldings. Differential Revision: https://phabricator.haskell.org/D4169
* Tidy up IfaceEqualityTyConSimon Peyton Jones2017-10-312-45/+44
| | | | | | | | | | | | | This commit commit 85aa1f4253163985fe07d172f8da73b784bb7b4b Date: Sun Oct 29 20:48:19 2017 -0400 Fix #14390 by making toIfaceTyCon aware of equality was a bit over-complicated. This patch simplifies the (horribly ad-hoc) treatement of IfaceEqualityTyCon, and documents it better. No visible change in behaviour.
* Fix #14390 by making toIfaceTyCon aware of equalityRyan Scott2017-10-291-0/+6
| | | | | | | | | | | | | | | | | | | | GHC was panicking when pretty-printing a heterogeneous equality type constructor (#14390) because the function which produced the type constructor, `toIfaceTyCon`, wasn't attaching the appropriate `IfaceTyConSort` for equality type constructors, which is `IfaceEqualityTyCon`. This is fixed easily enough. Test Plan: make test TEST=T14390 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14390 Differential Revision: https://phabricator.haskell.org/D4132
* Fix space leak in BinIface.getSymbolTableDouglas Wilson2017-10-251-10/+23
| | | | | | | | | | | | | | | | | | | | | | | | Replace a call to mapAccumR, which uses linear stack space, with a gadget that uses constant space. Remove an unused parameter from fromOnDiskName. The tests T1292_imports and T4239 are now reporting imported names in a different order. I don't completely understand why, but I presume it is because the symbol tables are now read more strictly. The new order seems better in T1792_imports, and equally random in T4239. There are several performance test improvements. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: alexbiehl, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4124
* Include usg_file_hash in ghc --show-iface outputSimon Marlow2017-10-241-1/+2
| | | | | | | | | | | | | | Summary: Otherwise we can get an iface hash difference, but no indication of what caused it in the --show-iface output. Test Plan: Harbourmaster Reviewers: austin, bgamari, erikd Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4115
* Levity polymorphic Backpack.Edward Z. Yang2017-10-161-3/+6
| | | | | | | | | | | | | | | | | | | | | This patch makes it possible to specify non * kinds of abstract data types in signatures, so you can have levity polymorphism through Backpack, without the runtime representation constraint! Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: andrewthad, bgamari, austin, goldfire Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #13955 Differential Revision: https://phabricator.haskell.org/D3825
* Track the order of user-written tyvars in DataConRyan Scott2017-10-035-45/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After typechecking a data constructor's type signature, its type variables are partitioned into two distinct groups: the universally quantified type variables and the existentially quantified type variables. Then, when prompted for the type of the data constructor, GHC gives this: ```lang=haskell MkT :: forall <univs> <exis>. (...) ``` For H98-style datatypes, this is a fine thing to do. But for GADTs, this can sometimes produce undesired results with respect to `TypeApplications`. For instance, consider this datatype: ```lang=haskell data T a where MkT :: forall b a. b -> T a ``` Here, the user clearly intended to have `b` be available for visible type application before `a`. That is, the user would expect `MkT @Int @Char` to be of type `Int -> T Char`, //not// `Char -> T Int`. But alas, up until now that was not how GHC operated—regardless of the order in which the user actually wrote the tyvars, GHC would give `MkT` the type: ```lang=haskell MkT :: forall a b. b -> T a ``` Since `a` is universal and `b` is existential. This makes predicting what order to use for `TypeApplications` quite annoying, as demonstrated in #11721 and #13848. This patch cures the problem by tracking more carefully the order in which a user writes type variables in data constructor type signatures, either explicitly (with a `forall`) or implicitly (without a `forall`, in which case the order is inferred). This is accomplished by adding a new field `dcUserTyVars` to `DataCon`, which is a subset of `dcUnivTyVars` and `dcExTyVars` that is permuted to the order in which the user wrote them. For more details, refer to `Note [DataCon user type variables]` in `DataCon.hs`. An interesting consequence of this design is that more data constructors require wrappers. This is because the workers always expect the first arguments to be the universal tyvars followed by the existential tyvars, so when the user writes the tyvars in a different order, a wrapper type is needed to swizzle the tyvars around to match the order that the worker expects. For more details, refer to `Note [Data con wrappers and GADT syntax]` in `MkId.hs`. Test Plan: ./validate Reviewers: austin, goldfire, bgamari, simonpj Reviewed By: goldfire, simonpj Subscribers: ezyang, goldfire, rwbarton, thomie GHC Trac Issues: #11721, #13848 Differential Revision: https://phabricator.haskell.org/D3687
* A bunch of typofixesGabor Greif2017-09-261-1/+1
|
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-1912-0/+23
| | | | | | | | | | | | | | | | | | This switches the compiler/ component to get compiled with -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all modules. This is motivated by the upcoming "Prelude" re-export of `Semigroup((<>))` which would cause lots of name clashes in every modulewhich imports also `Outputable` Reviewers: austin, goldfire, bgamari, alanz, simonmar Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari Differential Revision: https://phabricator.haskell.org/D3989
* Fix #13963.Richard Eisenberg2017-09-141-1/+3
| | | | | | | | | | | | | | | This commit fixes several things: 1. RuntimeRep arg suppression was overeager for *visibly*-quantified RuntimeReps, which should remain. 2. The choice of whether to used a Named TyConBinder or an anonymous was sometimes wrong. Now, we do an extra little pass right before constructing the tycon to fix these. 3. TyCons that normally cannot appear unsaturated can appear unsaturated in :kind. But this fact was not propagated into the type checker. It now is.
* Fix #13407 by suppressing invisibles better.Richard Eisenberg2017-09-141-3/+3
| | | | | | | Previously, the iface-invisible-suppresser assumed that all invisible things are up front. Not true! test case: ghci/scripts/T13407
* Fix #14167 by using isGadtSyntaxTyCon in more placesRyan Scott2017-09-022-28/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Two places in GHC effectively attempt to //guess// whether a data type was declared using GADT syntax: 1. When reifying a data type in Template Haskell 2. When pretty-printing a data type (e.g., via `:info` in GHCi) But there's no need for heuristics here, since we have a 100% accurate way to determine whether a data type was declared using GADT syntax: the `isGadtSyntaxTyCon` function! By simply using that as the metric, we obtain far more accurate TH reification and pretty-printing results. This is technically a breaking change, since Template Haskell reification will now reify some data type constructors as `(Rec)GadtC` that it didn't before, and some data type constructors that were previously reified as `(Rec)GadtC` will no longer be reified as such. But it's a very understandable breaking change, since the previous behavior was simply incorrect. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #14167 Differential Revision: https://phabricator.haskell.org/D3901
* Add missing Semigroup instances to compilerHerbert Valerio Riedel2017-08-311-3/+7
| | | | | This is a pre-requisite for implementing the Semigroup/Monoid proposal. The instances have been introduced in a way to minimise warnings.
* Add debugPprTypeSimon Peyton Jones2017-08-313-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | We pretty-print a type by converting it to an IfaceType and pretty-printing that. But (a) that's a bit indirect, and (b) delibrately loses information about (e.g.) the kind on the /occurrences/ of a type variable So this patch implements debugPprType, which pretty prints the type directly, with no fancy formatting. It's just used for debugging. I took the opportunity to refactor the debug-pretty-printing machinery a little. In particular, define these functions and use them: ifPprDeubug :: SDoc -> SDOc -> SDoc -- Says what to do with and without -dppr-debug whenPprDebug :: SDoc -> SDoc -- Says what to do with -dppr-debug; without is empty getPprDebug :: (Bool -> SDoc) -> SDoc getPprDebug used to be called sdocPprDebugWith whenPprDebug used to be called ifPprDebug So a lot of files get touched in a very mechanical way
* Small refactor of getRuntimeRepSimon Peyton Jones2017-08-291-1/+1
| | | | | | | | | Instead of using a string argument, use HasDebugCallStack. (Oddly, some functions were using both!) Plus, use getRuntimeRep rather than getRuntimeRep_maybe when if the caller panics on Nothing. Less code, and a better debug stack.
* Fix #14060 by more conservatively annotating TH-reified typesRyan Scott2017-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, TH was quite generous in applying kind annotations to reified type constructors whose result kind happened to mention type variables. This could result in agonizingly large reified types, so this patch aims to quell this a bit by adopting a more nuanced algorithm for determining when a tycon application deserves a kind annotation. This implements the algorithm laid out in https://ghc.haskell.org/trac/ghc/ticket/14060#comment:1. I've updated `Note [Kind annotations on TyConApps]` to reflect the new wisdom. Essentially, instead of only checking if the result kind contains free variables, we also check if any of those variables do not appear free in injective positions in the argument kinds—only then do we put on a kind annotation. Bumps `haddock` submodule. Test Plan: make test TEST=T14060 Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #14060 Differential Revision: https://phabricator.haskell.org/D3807
* Fix hs-boot knot-tying with record wild cards.Edward Z. Yang2017-07-281-1/+8
| | | | | | | | | | | | | | | | | | Fixes #13710. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13710 Differential Revision: https://phabricator.haskell.org/D3743
* Remove old coercion pretty-printerRichard Eisenberg2017-07-273-4/+5
| | | | | | | Now, all coercions are printed from IfaceType, just like types. This also changes the rendering of TransCo to use ; instead of a prefix operator.
* Preserve CoVar uniques during pretty printingRichard Eisenberg2017-07-274-4/+15
| | | | Previously, we did this for Types, but not for Coercions.
* Fix binder visiblity for default methodsSimon Peyton Jones2017-07-262-68/+4
| | | | | | | | | | | | | | | | | | | Trac #13998 showed that default methods were getting bogus tyvar binder visiblity info; and that it matters in the code genreated by the default-method fill-in mechanism * The actual fix: in TcTyDecls.mkDefaultMethodType, make TyVarBinders with the right visibility info by getting TyConBinders from the class TyCon. (Previously we made up visiblity info, but that caused #13998.) * Define TyCon.tyConTyVarBinders :: [TyConBinder] -> [TyVarBinder] which can build correct forall binders for a) default methods (Trac #13998) b) data constructors This was originally BuildTyCl.mkDataConUnivTyVarBinders * Move mkTyVarBinder, mkTyVarBinders from Type to Var
* Make IfaceAxiom typechecking lazier.Edward Z. Yang2017-07-201-1/+8
| | | | | | | | | | | | | | | | | | Fixes #13803, but adds a note about a yet to be fixed #13981. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13803 Differential Revision: https://phabricator.haskell.org/D3742
* Implement recompilation checking for -fignore-assertsÖmer Sinan Ağacan2017-07-031-1/+5
| | | | | | | | | | | | | | Test Plan: Added a test which was previously failing Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #13914 Differential Revision: https://phabricator.haskell.org/D3698
* Typos in commentsRyan Scott2017-06-291-1/+1
| | | | [ci skip]
* Refactor temp files cleanupDouglas Wilson2017-06-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove filesToNotIntermediateClean from DynFlags, create a data type FilesToClean, and change filesToClean in DynFlags to be a FilesToClean. Modify SysTools.newTempName and the Temporary constructor of PipelineMonad.PipelineOutput to take a TempFileLifetime, which specifies whether a temp file should live until the end of GhcMonad.withSession, or until the next time cleanIntermediateTempFiles is called. These changes allow the cleaning of intermediate files in GhcMake to be much more efficient. HscTypes.hptObjs is removed as it is no longer used. A new performance test T13701 is added, which passes both with and without -keep-tmp-files. The test fails by 25% without the patch, and passes when -keep-tmp-files is added. Note that there are still at two hotspots caused by algorithms quadratic in the number of modules, however neither of them allocate. They are: * DriverPipeline.compileOne'.needsLinker * GhcMake.getModLoop DriverPipeline.compileOne'.needsLinker is changed slightly to improve the situation. I don't like adding these Types to DynFlags, but they need to be seen by Dynflags, SysTools and PipelineMonad. The alternative seems to be to create a new module. Reviewers: austin, hvr, bgamari, dfeuer, niteria, simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13701 Differential Revision: https://phabricator.haskell.org/D3620
* Fix build after 'Shrink a couple of hs-boot files'Bartosz Nitka2017-05-272-3/+1
|
* Some tidying up of type pretty-printingSimon Peyton Jones2017-05-261-38/+49
| | | | | | | | | | | | | | | | | | | | | | | | | Triggered by the changes in #13677, I ended up doing a bit of refactoring in type pretty-printing. * We were using TyOpPrec and FunPrec rather inconsitently, so I made it consisent. * That exposed the fact that we were a bit undecided about whether to print a + b -> c + d vs (a+b) -> (c+d) and similarly a ~ [b] => blah vs (a ~ [b]) => blah I decided to make TyOpPrec and FunPrec compare equal (in BasicTypes), so (->) is treated as equal precedence with other type operators, so you get the unambiguous forms above, even though they have more parens. We could readily reverse this decision. See Note [Type operator precedence] in BasicTypes * I fixed a bug in pretty-printing of HsType where some parens were omitted by mistake.
* Shrink a couple of hs-boot filesSimon Peyton Jones2017-05-262-26/+8
| | | | | IfaceType.hs-boot and ToIface.hs-boot were bigger than they needed to be, so I'm shrinking them.
* Pretty-print strict record fields from ifaces correctlyRyan Scott2017-05-201-1/+9
| | | | | | | | | | | | | | | | | We need to use parentheses more when pretty-printing types with bang patterns within constructors that use record syntax. Fixes #13699. Test Plan: make test TEST=T13699 Reviewers: austin, bgamari, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, rwbarton, thomie GHC Trac Issues: #13699 Differential Revision: https://phabricator.haskell.org/D3587
* Account for IfUnpackCo in freeNamesIfDeclSimon Peyton Jones2017-05-191-2/+8
| | | | | | | | | We were simply failing to recognise all the free variables of an IfaceDecl, notably the ones in the coercion of an IfUnpackCo. Result: the dependency analysis got messed up, so that fingerprint calculation went wrong. Trac #13695 showed it up. A test case is tricky but the fix is a solid one.
* Refactor freeNamesIfDeclSimon Peyton Jones2017-05-191-44/+68
| | | | | This just switches to using pattern matching rather than field selectors, which I generally prefer. No change in behaviour.
* Comments and white space onlySimon Peyton Jones2017-05-191-3/+2
|
* Kill off unused IfaceType.eqIfaceTypeSimon Peyton Jones2017-05-162-120/+21
| | | | | Edward implemented these functions, but they aren't used any more. Trac #13679
View Lorry Controller Status