summaryrefslogtreecommitdiff
path: root/compiler/specialise/SpecConstr.hs
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Core operations (#13009)Sylvain Henry2020-03-181-2360/+0
|
* Modules: Core (#13009)Sylvain Henry2020-03-161-5/+5
| | | | Update submodule: haddock
* Modules: Core (#13009)Sylvain Henry2020-02-261-13/+13
| | | | Update haddock submodule
* Modules: Driver (#13009)Sylvain Henry2020-02-211-2/+2
| | | | submodule updates: nofib, haddock
* Separate CPR analysis from the Demand analyserwip/sep-cprSebastian Graf2020-02-121-1/+3
| | | | | | | | | | | | | | | | | | | The reasons for that can be found in the wiki: https://gitlab.haskell.org/ghc/ghc/wikis/nested-cpr/split-off-cpr We now run CPR after demand analysis (except for after the final demand analysis run just before code gen). CPR got its own dump flags (`-ddump-cpr-anal`, `-ddump-cpr-signatures`), but not its own flag to activate/deactivate. It will run with `-fstrictness`/`-fworker-wrapper`. As explained on the wiki page, this step is necessary for a sane Nested CPR analysis. And it has quite positive impact on compiler performance: Metric Decrease: T9233 T9675 T9961 T15263
* Disable two warnings for files that trigger themTom Ellis2020-01-271-0/+2
| | | | | | incomplete-uni-patterns and incomplete-record-updates will be in -Wall at a future date, so prepare for that by disabling those warnings on files that trigger them.
* Fix more typos, via an improved Levenshtein-style correctorBrian Wignall2020-01-121-4/+4
|
* Use "OrCoVar" functions lessKrzysztof Gogolewski2019-12-161-2/+2
| | | | | | | | | | | As described in #17291, we'd like to separate coercions and expressions in a more robust fashion. This is a small step in this direction. - `mkLocalId` now panicks on a covar. Calls where this was not the case were changed to `mkLocalIdOrCoVar`. - Don't use "OrCoVar" functions in places where we know the type is not a coercion.
* Drop Uniquable constraint for AnnTargetBen Gamari2019-12-031-1/+1
| | | | | | This relied on deriveUnique, which was far too subtle to be safely applied. Thankfully the instance doesn't appear to be used so let's just drop it.
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-14/+14
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Finish fix for #14880.Tobias Dammers2018-10-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591
* Coercion Quantificationningning2018-09-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corresponds to #15497. According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2, we would like to have coercion quantifications back. This will allow us to migrate (~#) to be homogeneous, instead of its current heterogeneous definition. This patch is (lots of) plumbing only. There should be no user-visible effects. An overview of changes: - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables, but only in *Core*. All relevant functions are updated accordingly. - Small changes that should be irrelevant to the main task: 1. removed dead code `mkTransAppCo` in Coercion 2. removed out-dated Note Computing a coercion kind and roles in Coercion 3. Added `Eq4` in Note Respecting definitional equality in TyCoRep, and updated `mkCastTy` accordingly. 4. Various updates and corrections of notes and typos. - Haddock submodule needs to be changed too. Acknowledgments: This work was completed mostly during Ningning Xie's Google Summer of Code, sponsored by Google. It was advised by Richard Eisenberg, supported by NSF grant 1704041. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar Subscribers: RyanGlScott, monoidal, rwbarton, carter GHC Trac Issues: #15497 Differential Revision: https://phabricator.haskell.org/D5054
* Comments onlySimon Peyton Jones2018-08-311-1/+1
|
* vectorise: Put it out of its miseryBen Gamari2018-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | Poor DPH and its vectoriser have long been languishing; sadly it seems there is little chance that the effort will be rekindled. Every few years we discuss what to do with this mass of code and at least once we have agreed that it should be archived on a branch and removed from `master`. Here we do just that, eliminating heaps of dead code in the process. Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and `primitive` submodules. Test Plan: Validate Reviewers: simonpj, simonmar, hvr, goldfire, alanz Reviewed By: simonmar Subscribers: goldfire, rwbarton, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4761
* SpecConstr: accommodate casts in value argumentsSimon Peyton Jones2018-04-021-9/+47
| | | | | | | | | | | | | | | | | | | | | | This commit: commit fb050a330ad202c1eb43038dc18cca2a5be26f4a Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Thu Oct 12 11:00:19 2017 +0100 Do not bind coercion variables in SpecConstr rules arranged to reject any SpecConstr call pattern that mentioned a coercion in the pattern. There was a good reason for that -- see Note [SpecConstr and casts] -- but I didn't realise how important it was to accept patterns that mention casts in /terms/. Trac #14936 showed this up. This patch just narrows the restriction to discard only the cases where the coercion is mentioned only in types. Fortunately that was pretty easy to do.
* Catch a few more typos in commentsGabor Greif2017-10-301-2/+2
|
* Fix typo in accessor nameGabor Greif2017-10-301-1/+1
| | | | and in comments
* Fix an exponential-blowup case in SpecConstrSimon Peyton Jones2017-10-271-20/+33
| | | | | | | | | Trac #14379 showed a case where use of "forcing" to do "damn the torpedos" specialisation without resource limits (which 'vector' does a lot) led to exponential blowup. The fix is easy. Finding it wasn't. See Note [Forcing specialisation] and the one-line change in decreaseSpecCount.
* Add more pprTrace to SpecConstr (debug only)Simon Peyton Jones2017-10-271-3/+11
|
* Do not bind coercion variables in SpecConstr rulesSimon Peyton Jones2017-10-121-2/+42
| | | | | | | | | | | | | | | | Trac #14270 showed that SpecConstr could cause nasty Lint failures if it generates a RULE that binds coercion varables. See * Note [SpecConstr and casts], and * the test simplCore/should_compile/T14270. This doesn't feel like the final word to me, because somehow the specialisation "ought" to work. So I left in a debug WARN to yell if the new check acutally fires. Meanwhile, it stops the erroneous specialisation. binding coercion
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | 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 typos in diagnostics, testsuite and commentsGabor Greif2017-09-071-1/+1
|
* Use lengthIs and friends in more placesRyan Scott2017-06-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | While investigating #12545, I discovered several places in the code that performed length-checks like so: ``` length ts == 4 ``` This is not ideal, since the length of `ts` could be much longer than 4, and we'd be doing way more work than necessary! There are already a slew of helper functions in `Util` such as `lengthIs` that are designed to do this efficiently, so I found every place where they ought to be used and did just that. I also defined a couple more utility functions for list length that were common patterns (e.g., `ltLength`). Test Plan: ./validate Reviewers: austin, hvr, goldfire, bgamari, simonmar Reviewed By: bgamari, simonmar Subscribers: goldfire, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3622
* Typos [ci skip]Gabor Greif2017-05-101-2/+2
|
* Fix loss-of-SpecConstr bugSimon Peyton Jones2017-05-021-86/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | This bug, reported in Trac #13623 has been present since commit b8b3e30a6eedf9f213b8a718573c4827cfa230ba Author: Edward Z. Yang <ezyang@cs.stanford.edu> Date: Fri Jun 24 11:03:47 2016 -0700 Axe RecFlag on TyCons. SpecConstr tries not to specialise indefinitely, and had a limit (see Note [Limit recursive specialisation]) that made use of info about whether or not a data constructor was "recursive". This info vanished in the above commit, making the limit fire much more often -- and indeed it fired in this test case, in a situation where specialisation is /highly/ desirable. I refactored the test, to look instead at the number of iterations of the loop of "and now specialise calls that arise from the specialisation". Actually less code, and more robust. I also added record field names to a couple of constructors, and renamed RuleInfo to SpecInfo.
* Improve SpecConstr when there are many opportunitiesSimon Peyton Jones2017-05-021-43/+113
| | | | | | | | | | | | | | SpecConstr has -fspec-contr-count=N which limits the maximum number of specialisations we make for any particular function. But until now, if that limit was exceeded we discarded all the candidates! So adding a new specialisaiton opportunity (by adding a new call site, or improving the optimiser) could result in less specialisation and worse performance. This patch instead picks the top N candidates, resulting in less brittle behaviour. See Note [Choosing patterns].
* Typos in comments [ci skip]Gabor Greif2017-04-051-1/+1
|
* Typos in changelog and commentsGabor Greif2017-03-071-1/+1
|
* Add -fspec-constr-keenSimon Peyton Jones2017-02-261-7/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | I discovered that the dramatic imprvoement in perf/should_run/T9339 with the introduction of join points was really rather a fluke, and very fragile. The real problem (see Note [Making SpecConstr keener]) is that SpecConstr wasn't specialising a function even though it was applied to a freshly-allocated constructor. The paper describes plausible reasons for this, but I think it may well be better to be a bit more aggressive. So this patch add -fspec-constr-keen, which makes SpecConstr a bit keener to specialise, by ignoring whether or not the argument corresponding to a call pattern is scrutinised in the function body. Now the gains in T9339 should be robust; and it might even be a better default. I'd be interested in what happens if we switched on -fspec-constr-keen with -O2. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3186
* More tracing in SpecConstrSimon Peyton Jones2017-02-231-4/+10
| | | | | | | | | | Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3179
* Add some commented-out tracing in SpecConstrSimon Peyton Jones2017-02-081-5/+9
|
* Ditch static flagsSylvain Henry2017-02-021-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | This patch converts the 4 lasting static flags (read from the command line and unsafely stored in immutable global variables) into dynamic flags. Most use cases have been converted into reading them from a DynFlags. In cases for which we don't have easy access to a DynFlags, we read from 'unsafeGlobalDynFlags' that is set at the beginning of each 'runGhc'. It's not perfect (not thread-safe) but it is still better as we can set/unset these 4 flags before each run when using GHC API. Updates haddock submodule. Rebased and finished by: bgamari Test Plan: validate Reviewers: goldfire, erikd, hvr, austin, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2839 GHC Trac Issues: #8440
* Join pointsLuke Maurer2017-02-011-9/+14
| | | | | | | | | | | | | | | | | | | This major patch implements Join Points, as described in https://ghc.haskell.org/trac/ghc/wiki/SequentCore. You have to read that page, and especially the paper it links to, to understand what's going on; but it is very cool. It's Luke Maurer's work, but done in close collaboration with Simon PJ. This Phab is a squash-merge of wip/join-points branch of http://github.com/lukemaurer/ghc. There are many, many interdependent changes. Reviewers: goldfire, mpickering, bgamari, simonmar, dfeuer, austin Subscribers: simonpj, dfeuer, mpickering, Mikolaj, thomie Differential Revision: https://phabricator.haskell.org/D2853
* Typos in comments only [ci skip]Gabor Greif2017-01-181-1/+1
|
* Move InId/OutId to CoreSynSimon Peyton Jones2016-12-211-9/+0
| | | | | | | | It turned out that many different modules defined the same type synonyms (InId, OutId, InType, OutType, etc) for the same purpose. This patch is refactoring only: it moves all those definitions to CoreSyn.
* Allow use of the external interpreter in stage1.Shea Levy2016-12-201-16/+3
| | | | | | | | | | | | | | | | | | | Summary: Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. This was originally added in https://phabricator.haskell.org/D2826 but that led to a compatibility issue with ghc 7.10.x on Windows. That's fixed here and the revert reverted. Reviewers: goldfire, hvr, austin, bgamari, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2884 GHC Trac Issues: #13008
* Revert "Allow use of the external interpreter in stage1."Tamar Christina2016-12-191-3/+16
| | | | This reverts commit 52ba9470a7e85d025dc84a6789aa809cdd68b566.
* Allow use of the external interpreter in stage1.Shea Levy2016-12-171-16/+3
| | | | | | | | | | | | Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. Reviewers: simonmar, goldfire, austin, hvr, bgamari Reviewed By: simonmar Subscribers: RyanGlScott, mpickering, angerman, thomie Differential Revision: https://phabricator.haskell.org/D2826
* Replace INLINEABLE by INLINABLE (#12613)Joachim Breitner2016-09-241-1/+1
| | | | | | | | | | 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.
* 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
* 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
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* 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
* 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.
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-181-15/+15
| | | | | | | | | | | | | | | | | | | | 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
* 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-111-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
View Lorry Controller Status