summaryrefslogtreecommitdiff
path: root/compiler/specialise
Commit message (Collapse)AuthorAgeFilesLines
* Replace INLINEABLE by INLINABLE (#12613)Joachim Breitner2016-09-242-8/+8
| | | | | | | | | | as the latter is the official, correct spelling, and the former just a misspelling accepted by GHC. Also document in the user’s guide that the alternative spelling is accepted This commit was brough to you by HIW 2016.
* Fix #12442.Richard Eisenberg2016-09-231-2/+2
| | | | | | | | | | | | | | | | | | | The problem is described in the ticket. This patch adds new variants of the access points to the pure unifier that allow unification of types only when the caller wants this behavior. (The unifier used to also unify kinds.) This behavior is appropriate when the kinds are either already known to be the same, or the list of types provided are a list of well-typed arguments to some type constructor. In the latter case, unifying earlier types in the list will unify the kinds of any later (dependent) types. At use sites, I went through and chose the unification function according to the criteria above. This patch includes some modest performance improvements as we are now doing less work.
* Comments and white spaceSimon Peyton Jones2016-09-131-1/+1
|
* extend '-fmax-worker-args' limit to specialiser (Trac #11565)Sergei Trofimovich2016-09-021-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's a complementary change to a48de37dcca98e7d477040b0ed298bcd1b3ab303 restore -fmax-worker-args handling (Trac #11565) I don't have a small example but I've noticed another discrepancy when was profiling GHC for performance cmmExprNative :: ReferenceKind -> CmmExpr -> CmmOptM CmmExpr was specialised by 'spec_one' down to a function with arity 159. As a result 'perf record' pointed at it as at slowest function in whole ghc library. I've extended -fmax-worker-args effect to 'spec_one' as it does the same worker/wrapper split to push arguments to the heap. The change decreases heap usage on a synth.bash benchmark (Trac #9221) from 67G down to 64G (-4%). Benchmark runtime decreased from 14.5 s down to 14.s (-7%). Signed-off-by: Sergei Trofimovich <siarheit@google.com> Reviewers: ezyang, simonpj, austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2507 GHC Trac Issues: #11565
* Introduce BootUnfolding, set when unfolding is absent due to hs-boot file.Edward Z. Yang2016-08-211-0/+1
| | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2246
* More typos in commentsGabor Greif2016-07-221-3/+3
|
* Axe RecFlag on TyCons.Edward Z. Yang2016-06-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit removes the information about whether or not a TyCon is "recursive", as well as the code responsible for calculating this information. The original trigger for this change was complexity regarding how we computed the RecFlag for hs-boot files. The problem is that in order to determine if a TyCon is recursive or not, we need to determine if it was defined in an hs-boot file (if so, we conservatively assume that it is recursive.) It turns that doing this is quite tricky. The "obvious" strategy is to typecheck the hi-boot file (since we are eventually going to need the typechecked types to check if we properly implemented the hi-boot file) and just extract the names of all defined TyCons from the ModDetails, but this actually does not work well if Names from the hi-boot file are being knot-tied via if_rec_types: the "extraction" process will force thunks, which will force the typechecking process earlier than we have actually defined the types locally. Rather than work around all this trickiness (it certainly can be worked around, either by making interface loading MORE lazy, or just reading of the set of defined TyCons directly from the ModIface), we instead opted to excise the source of the problem, the RecFlag. For one, it is not clear if the RecFlag even makes sense, in the presence of higher-orderness: data T f a = MkT (f a) T doesn't look recursive, but if we instantiate f with T, then it very well is! It was all very shaky. So we just don't bother anymore. This has two user-visible implications: 1. is_too_recursive now assumes that all TyCons are recursive and will bail out in a way that is still mysterious to me if there are too many TyCons. 2. checkRecTc, which is used when stripping newtypes to get to representation, also assumes all TyCons are recursive, and will stop running if we hit the limit. The biggest risk for this patch is that we specialize less than we used to; however, the codeGen tests still seem to be passing. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Reviewers: simonpj, austin, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2360
* Typos in comments [skip ci]Gabor Greif2016-06-221-2/+2
|
* Don't quantify over Refl in a RULESimon Peyton Jones2016-06-211-6/+29
| | | | | | | This fixes Trac #12212. It's quite hard to provoke, but I've added a standalone test case that does so. The issue is explained in Note [Evidence foralls] in Specialise.
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-152-2/+2
| | | | | | | | | | | | | | | | | | | | | | With TypeInType Richard combined ForAllTy and FunTy, but that was often awkward, and yielded little benefit becuase in practice the two were always treated separately. This patch re-introduces FunTy. Specfically * New type data TyVarBinder = TvBndr TyVar VisibilityFlag This /always/ has a TyVar it. In many places that's just what what we want, so there are /lots/ of TyBinder -> TyVarBinder changes * TyBinder still exists: data TyBinder = Named TyVarBinder | Anon Type * data Type = ForAllTy TyVarBinder Type | FunTy Type Type | .... There are a LOT of knock-on changes, but they are all routine. The Haddock submodule needs to be updated too
* Rename cmpType to nonDetCmpTypeBartosz Nitka2016-06-141-2/+2
| | | | | | | This makes it obvious that it's nondeterministic and hopefully will prevent someone from using it accidentally. GHC Trac: #4012
* Implement deterministic CallInfoSetBartosz Nitka2016-06-061-37/+74
| | | | | | | | | | | | | | | | | | | | | | | We need CallInfoSet to be deterministic because it determines the order that the binds get generated. Currently it's not deterministic because it's keyed on `CallKey = [Maybe Type]` and `Ord CallKey` is implemented with `cmpType` which is nondeterministic. See Note [CallInfoSet determinism] for more details. Test Plan: ./validate Reviewers: simonpj, bgamari, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2242 GHC Trac Issues: #4012
* Localize orphan-related nondeterminismBartosz Nitka2016-06-021-2/+2
| | | | | | | | | | | | | | | chooseOrphanAnchor now takes a NameSet, relieving the callers from the burden of converting it to a list Test Plan: ./validate Reviewers: bgamari, ezyang, austin, simonmar, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2294 GHC Trac Issues: #4012
* Document some benign nondeterminismBartosz Nitka2016-05-241-1/+3
| | | | | | | | | | | | | | | | | | I've changed the functions to their nonDet equivalents and explained why they're OK there. This allowed me to remove foldNameSet, foldVarEnv, foldVarEnv_Directly, foldVarSet and foldUFM_Directly. Test Plan: ./validate, there should be no change in behavior Reviewers: simonpj, simonmar, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2244 GHC Trac Issues: #4012
* Refactor some ppr functions to use pprUFMBartosz Nitka2016-05-121-2/+4
| | | | | | | | | | | | | | | | | Nondeterminism doesn't matter in these places and pprUFM makes it obvious. I've flipped the order of arguments for convenience. Test Plan: ./validate Reviewers: simonmar, bgamari, austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2205 GHC Trac Issues: #4012
* Kill varEnvElts in specImportsBartosz Nitka2016-05-121-10/+18
| | | | | | | | | | | | | | | | | We need the order of specialized binds and rules to be deterministic, so we use a deterministic set here. Test Plan: ./validate Reviewers: simonmar, bgamari, austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2197 GHC Trac Issues: #4012
* Add uniqSetAny and uniqSetAll and use themBartosz Nitka2016-04-281-1/+1
| | | | | | | | | | | | | | | | | | There are couple of places where we do `foldUniqSet` just to compute `any` or `all`. `foldUniqSet` is non-deterministic in the general case and `any` and `all` also read nicer. Test Plan: ./validate Reviewers: simonmar, goldfire, simonpj, bgamari, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2156 GHC Trac Issues: #4012
* Kill some unnecessary varSetElemsBartosz Nitka2016-04-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to `tyCoVarsOfTypeList x`. Why? If you look at the implementation: ``` tyCoVarsOfTypeList ty = runFVList $ tyCoVarsOfTypeAcc ty tyCoVarsOfType ty = runFVSet $ tyCoVarsOfTypeAcc ty ``` they use the same helper function. The helper function returns a deterministically ordered list and a set. The only difference between the two is which part of the result they take. It is redundant to take the set and then immediately convert it to a list. This helps with determinism and we eventually want to replace the uses of `varSetElems` with functions that don't leak the values of uniques. This change gets rid of some instances that are easy to kill. I chose not to annotate every place where I got rid of `varSetElems` with a comment about non-determinism, because once we get rid of `varSetElems` it will not be possible to do the wrong thing. Test Plan: ./validate Reviewers: goldfire, austin, simonmar, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2115 GHC Trac Issues: #4012
* Demand Analyzer: Do not set OneShot information (second try)Joachim Breitner2016-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | as suggested in ticket:11770#comment:1. This code was buggy (#11770), and the occurrence analyzer does the same job anyways. This also elaborates the notes in the occurrence analyzer accordingly. Previously, the worker/wrapper code would go through lengths to transfer the oneShot annotations from the original function to both the worker and the wrapper. We now simply transfer the demand on the worker, and let the subsequent occurrence analyzer push this onto the lambda binders. This also requires the occurrence analyzer to do this more reliably. Previously, it would not hand out OneShot annotatoins to things that would not `certainly_inline` (and it might not have mattered, as the Demand Analysis might have handed out the annotations). Now we hand out one-shot annotations unconditionally. Differential Revision: https://phabricator.haskell.org/D2085
* Kill the magic of AnyBen Gamari2016-03-301-1/+1
| | | | | | | | | | | | | | | | | | | | This turns `Any` into a standard wired-in type family defined in `GHC.Types`, instead its current incarnation as a magical creature provided by the `GHC.Prim`. Also kill `AnyK`. See #10886. Test Plan: Validate Reviewers: simonpj, goldfire, austin, hvr Reviewed By: simonpj Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2049 GHC Trac Issues: #10886
* Typos in non-codeGabor Greif2016-03-301-1/+1
|
* SpecConstr: Transport strictness data to specialization’s argument’s bindersJoachim Breitner2016-03-291-1/+25
| | | | This is a result of the discussion in ticket:11731#comment:9.
* Tidy up handling of coercion variablesSimon Peyton Jones2016-03-241-4/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * Comments to explain that a CoVar, whose IdInfo is CoVarId, is always unlifted (but may be nominal or representational role) And TyCoRep.isCoercionType picks out only those unlifted types, NOT the lifted versions * Introduce Var.NcId for non-co-var Ids with predicate isNonCoVarId * Add assertions in CoreSubst that the Id env is only used for NcIds * Fix lurking bug in CSE which extended the CoreSubst Id env with a CoVar * Fix two bugs in Specialise.spec_call, which wrongly treated CoVars like NcIds - needed a varToCoreExpr in one place - needed extendSubst not extendIdSubst in another This was the root cause of Trac #11644 Minor refactoring * Eliminate unused mkDerivedLocalCoVarM, mkUserLocalCoVar * Small refactor in mkSysLocalOrCoVar
* Get the right in-scope set in specUnfoldingSimon Peyton Jones2016-02-261-5/+16
| | | | This fixes Trac #11600
* A few more typos in non-codeGabor Greif2016-02-191-1/+1
|
* (Another) minor refactoring of substitutionsSimon Peyton Jones2016-02-181-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | No change in functionality here, but greater clarity: * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field We are already maintaining an in-scope set in the fe_subst field, so it's silly do to it twice. (This isn't strictly connected to the rest of this patch, but the nomenclature changes below affect the same code, so I put them together.) * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work out what to do, but in fact we almost always know which of the two we are doing. So: - define extendTvSubst, extendCvSubst - and use them * Similar renamings in TyCoRep: - extendTCvSubstList --> extendTvSubstList - extendTCvSubstBinder --> extendTvSubstBinder - extendTCvSubstAndInScope --> extendTvSubstAndInScope * Add Type.extendTvSubstWithClone, extendCvSubstWithClone * Similar nomenclature changes in Subst, SimplEnv, Specialise * Kill off TyCoRep.substTelescope (never used)
* Another batch of typo fixes in non-codeGabor Greif2016-02-111-1/+1
|
* s/unLifted/unlifted for consistencyÖmer Sinan Ağacan2016-01-271-1/+1
| | | | | | | | | | | | | This was causing trouble as we had to remember when to use "unLifted" and when to use "unlifted". "unlifted" is used instead of "unLifted" as it's a single word. Reviewers: austin, hvr, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1852
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-183-36/+36
| | | | | | | | | | | | | | | | | | | | Summary: In the past the canonical way for constructing an SDoc string literal was the composition `ptext . sLit`. But for some time now we have function `text` that does the same. Plus it has some rules that optimize its runtime behaviour. This patch takes all uses of `ptext . sLit` in the compiler and replaces them with calls to `text`. The main benefits of this patch are clener (shorter) code and less dependencies between module, because many modules now do not need to import `FastString`. I don't expect any performance benefits - we mostly use SDocs to report errors and it seems there is little to be gained here. Test Plan: ./validate Reviewers: bgamari, austin, goldfire, hvr, alanz Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1784
* Remove some redundant definitions/constraintsHerbert Valerio Riedel2015-12-311-1/+0
| | | | | | Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`, which allows to simplify some definitions to exploit the superclass relationship. This a first refactoring to that end.
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-311-3/+0
| | | | | | | | | | | | Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP compatibility CPP-mess for good! Reviewers: austin, goldfire, bgamari Subscribers: goldfire, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1724
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (Apologies for the size of this patch, I couldn't make a smaller one that was validate-clean and also made sense independently) (Some of this code is derived from GHCJS.) This commit adds support for running interpreted code (for GHCi and TemplateHaskell) in a separate process. The functionality is experimental, so for now it is off by default and enabled by the flag -fexternal-interpreter. Reaosns we want this: * compiling Template Haskell code with -prof does not require building the code without -prof first * when GHC itself is profiled, it can interpret unprofiled code, and the same applies to dynamic linking. We would no longer need to force -dynamic-too with TemplateHaskell, and we can load ordinary objects into a dynamically-linked GHCi (and vice versa). * An unprofiled GHCi can load and run profiled code, which means it can use the stack-trace functionality provided by profiling without taking the performance hit on the compiler that profiling would entail. Amongst other things; see https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details. Notes on the implementation are in Note [Remote GHCi] in the new module compiler/ghci/GHCi.hs. It probably needs more documenting, feel free to suggest things I could elaborate on. Things that are not currently implemented for -fexternal-interpreter: * The GHCi debugger * :set prog, :set args in GHCi * `recover` in Template Haskell * Redirecting stdin/stdout for the external process These are all doable, I just wanted to get to a working validate-clean patch first. I also haven't done any benchmarking yet. I expect there to be slight hit to link times for byte code and some penalty due to having to serialize/deserialize TH syntax, but I don't expect it to be a serious problem. There's also lots of low-hanging fruit in the byte code generator/linker that we could exploit to speed things up. Test Plan: * validate * I've run parts of the test suite with EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th. There are a few failures due to the things not currently implemented (see above). Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1562
* Add kind equalities to GHC.Richard Eisenberg2015-12-113-54/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule.
* Make callToPats deterministic in SpecConstrBartosz Nitka2015-12-041-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a non-determinism bug where where depending on the order of uniques allocated, the specialized workers would have different order of arguments. Compare: ``` $s$wgo_s1CN :: Int# -> Int -> Int# [LclId, Arity=2, Str=DmdType <L,U><L,U>] $s$wgo_s1CN = \ (sc_s1CI :: Int#) (sc_s1CJ :: Int) -> case tagToEnum# @ Bool (<=# sc_s1CI 0#) of _ [Occ=Dead] { False -> $wgo_s1BU (Just @ Int (I# (-# sc_s1CI 1#))) (Just @ Int sc_s1CJ); True -> 0# } ``` vs ``` $s$wgo_s18mTj :: Int -> Int# -> Int# [LclId, Arity=2, Str=DmdType <L,U><L,U>] $s$wgo_s18mTj = \ (sc_s18mTn :: Int) (sc_s18mTo :: Int#) -> case tagToEnum# @ Bool (<=# sc_s18mTo 0#) of _ [Occ=Dead] { False -> $wgo_s18mUc (Just @ Int (I# (-# sc_s18mTo 1#))) (Just @ Int sc_s18mTn); True -> 0# } ``` Test Plan: I've added a new testcase ./validate Reviewers: simonmar, simonpj, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1508 GHC Trac Issues: #4012
* Implement more deterministic operations and document themBartosz Nitka2015-12-021-3/+3
| | | | | | | | | | | | | | | | I will need them for the future determinism fixes. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari, austin, hvr, simonmar Reviewed By: simonpj, simonmar Subscribers: osa1, thomie Differential Revision: https://phabricator.haskell.org/D1537 GHC Trac Issues: #4012
* Create a deterministic version of tyVarsOfTypeBartosz Nitka2015-11-211-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | I've run into situations where I need deterministic `tyVarsOfType` and this implementation achieves that and also brings an algorithmic improvement. Union of two `VarSet`s takes linear time the size of the sets and in the worst case we can have `n` unions of sets of sizes `(n-1, 1), (n-2, 1)...` making it quadratic. One reason why we need deterministic `tyVarsOfType` is in `abstractVars` in `SetLevels`. When we abstract type variables when floating we want them to be abstracted in deterministic order. Test Plan: harbormaster Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1468 GHC Trac Issues: #4012
* MonadFail proposal, phase 1David Luposchainsky2015-11-171-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | This implements phase 1 of the MonadFail proposal (MFP, #10751). - MonadFail warnings are all issued as desired, tunable with two new flags - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings` (but it's disabled by default right now) Credits/thanks to - Franz Thoma, whose help was crucial to implementing this - My employer TNG Technology Consulting GmbH for partially funding us for this work Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma Reviewed By: hvr, bgamari, fmthoma Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1248 GHC Trac Issues: #10751
* Put kind variables before type variables when specializingBartosz Nitka2015-11-111-5/+6
| | | | | | | | | | | | | | | | | | | | | | | When you reverse the order of uniques you get the core lint error from the testcase. The testcase is copied from tests/simplCore/should_compile/T10689a.hs. The problem is that we would put type and kind variables ordered by unique order, which happened to be the right order for this testcase to pass under normal conditions. I think it's enough to sort them with `sortQuantVars`, but I'm not really sure if some more sophisticated dependency analysis isn't needed. Test Plan: added a new testcase Reviewers: simonpj, goldfire, simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1457
* Make Monad/Applicative instances MRP-friendlyHerbert Valerio Riedel2015-10-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e. such that the explicit definitions for `return` and `(>>)` match the MRP-style default-implementation, i.e. return = pure and (>>) = (*>) This way, e.g. all `return = pure` definitions can easily be grepped and removed in GHC 8.1; Test Plan: Harbormaster Reviewers: goldfire, alanz, bgamari, quchen, austin Reviewed By: quchen, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1312
* Rename SpecInfo to RuleInfo (upon SPJ's advice).Edward Z. Yang2015-10-103-25/+25
| | | | | | | | | | | | Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1319
* Move orphan instance/rule warnings to typechecker/desugarer.Edward Z. Yang2015-10-081-0/+20
| | | | | | | | | | | | | | | | | | | | | | Summary: Instead of doing these warnings at MkIface time, we do them when we create the instances/rules in the typechecker/desugarer. Emitting warnings for auto-generated instances was a pain (since the specialization monad doesn't have the capacity to emit warnings) so instead I just deprecated -fwarn-auto-orphans. Auto rule orphans are pretty harmless anyway: they don't cause interface files to be eagerly loaded in. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1297
* Remove dead code: ruleLhsOrphNamesSimon Peyton Jones2015-10-061-1/+0
|
* Testsuite: don't warn about missing specialisationsThomas Miedema2015-09-021-0/+1
| | | | | | | | | They can only occur with `-O`, but we want tests to produce the same output for all test ways. This brings us closer to passing the complete testsuite. Differential Revision: https://phabricator.haskell.org/D1203
* Warn about missed specialisations for importsSimon Peyton Jones2015-08-051-16/+49
| | | | | | | | | | | | | | | This change was provoked by Trac #10720, where a missing INLINEABLE pragma gave very poor performance. The change is to warn when an imported function is not specialised in a situation where the user expects it to be. New flags -fwarn-missed-specialisations -fwarn-all-missed-specialisations Documented in user manual. See Note [Warning about missed specialisations]
* Typos in comments [skip ci]Gabor Greif2015-08-031-1/+1
|
* Deal with phantom type variables in rulesSimon Peyton Jones2015-07-301-42/+78
| | | | | | | | | | | | | | | | | See Note [Unbound template type variables] in Rules.hs This fixes Trac #10689. The problem was a rule LHS that mentioned a type variable in a phantom argument to a type synonym. Then matching the LHS didn't bind the type variable, and the rule matcher complained. This patch fixes the problem, as described by the Note. I also went back to not-cloning the template varaibles during rule matching. I'm convinced that it's not necessary now (if it ever was), and cloning makes the fix for #10689 much more fiddly.
* Slight refactoring to the fix for #4012Simon Peyton Jones2015-07-231-5/+2
| | | | Add CoreSyn.chooseOrphanAnchor, and use it
* Do occurrence analysis on result of BuiltInRuleSimon Peyton Jones2015-07-211-2/+3
| | | | | | | | Previously we did occurrence analysis on the result of a non-built-in RULE, but not of a built-in one. It makes a difference if the rule returns something with binders (which admittedly it usually does not). I'm about to introduce just such a rule for 'seq'.
* Avoid out-of-scope top-level IdsSimon Peyton Jones2015-07-211-16/+15
| | | | | | Pass the top-level SpecEnv to specImports/specImport, so that top-level Ids are in scope. Otherwise we get annoying (but correct) WARNINGS.
* Reduce non-determinism in ABI hashes with RULES and instance declsBartosz Nitka2015-07-171-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this change the `RULES` would be attached to one for the names from the module that appear on the left hand side. The choice depended on the `uniq` that was generated, which are known to be non-deterministic (a separate, bigger problem). Now we use `OccName`s which should be stable. Analogously for instance declarations, but they are attached to one of the types involved. Test Plan: contbuild it made `Data.Text.Internal.Fusion.Common` interface stable, previously stream fusion rule would be attached either to `streamList` or `unstreamList` depending on if the module was compiled after `cabal clean` or after `find | grep '\.o$' | xargs rm`. Reviewers: simonpj, austin, bgamari, simonmar Subscribers: puffnfresh, thomie Differential Revision: https://phabricator.haskell.org/D1073 GHC Trac Issues: #4012
View Lorry Controller Status