summaryrefslogtreecommitdiff
path: root/compiler/deSugar
Commit message (Collapse)AuthorAgeFilesLines
* Prefer #if defined to #ifdefBen Gamari2017-04-281-1/+1
| | | | Our new CPP linter enforces this.
* Comments and tiny refactoringSimon Peyton Jones2017-04-281-0/+1
|
* Typos in comments [ci skip]Gabor Greif2017-04-112-2/+2
|
* Fix validate.Edward Z. Yang2017-04-031-1/+0
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Fix recompilation avoidance bug for implementor of hsig.Edward Z. Yang2017-04-021-5/+14
| | | | | | | | | | | | | | | | | | | | | Summary: I observed a bug where if I modified the module which implemented an hsig in another package, GHC would not recompile the signature in this situation. The root cause was that we were conflating modules from user imports, and "system" module dependencies (from signature merging and instantiation.) So this patch handles them separately. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, bgamari, austin Subscribers: rwbarton, thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3381
* Typos in comments [ci skip]Gabor Greif2017-03-301-1/+1
|
* No join-point from an INLINE function with wrong aritySimon Peyton Jones2017-03-172-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | The main payload of this patch is NOT to make a join-point from a function with an INLINE pragma and the wrong arity; see Note [Join points and INLINE pragmas] in CoreOpt. This is what caused Trac #13413. But we must do the exact same thing in simpleOptExpr, which drove me to the following refactoring: * Move simpleOptExpr and simpleOptPgm from CoreSubst to a new module CoreOpt along with a few others (exprIsConApp_maybe, pushCoArg, etc) This eliminates a module loop altogether (delete CoreArity.hs-boot), and stops CoreSubst getting too huge. * Rename Simplify.matchOrConvertToJoinPoint to joinPointBinding_maybe Move it to the new CoreOpt Use it in simpleOptExpr as well as in Simplify * Define CoreArity.joinRhsArity and use it
* Fix #12709 by not building bad applicationsRichard Eisenberg2017-03-174-14/+38
| | | | | | | | | | | In an effort to report multiple levity polymorphism errors all at once, the desugarer does not fail when encountering bad levity polymorphism. But we must be careful not to build the bad applications, lest they try to satisfy the let/app invariant and call isUnliftedType on a levity polymorphic type. This protects calls to mkCoreAppDs appropriately. test case: typecheck/should_fail/T12709
* Introduce putLogMsgBen Gamari2017-03-151-1/+1
| | | | | | | | | | | | | This factors out the repetition of (log_action dflags dflags) and will hopefully allow us to someday better abstract log output. Test Plan: Validate Reviewers: austin, hvr, goldfire Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3334
* Introduce and use mkLetRec, mkLetNonRecBen Gamari2017-03-141-2/+1
| | | | | | | | | | Test Plan: Validate Reviewers: austin Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3303
* Remove `runs` function which already exists in baseÖmer Sinan Ağacan2017-03-122-6/+6
| | | | | | | | | | Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3320
* dsGRHSs: Remove unused pattern variables argumentÖmer Sinan Ağacan2017-03-112-4/+4
|
* Allow compilation of C/C++/ObjC/ObjC++ files with module from THFrancesco Mazzoli2017-03-081-4/+4
| | | | | | | | | | | | | | | | | | | | The main goal is to easily allow the inline-c project (and similar projects such as inline-java) to emit C/C++ files to be compiled and linked with the current module. Moreover, `addCStub` is removed, since it's quite fragile. Most notably, the C stubs end up in the file generated by `CodeOutput.outputForeignStubs`, which is tuned towards generating a file for stubs coming from `capi` and Haskell-to-C exports. Reviewers: simonmar, austin, goldfire, facundominguez, dfeuer, bgamari Reviewed By: dfeuer, bgamari Subscribers: snowleopard, rwbarton, dfeuer, thomie, duncan, mboes Differential Revision: https://phabricator.haskell.org/D3280
* Desugar: Refactor initDsBen Gamari2017-03-072-55/+74
| | | | | | | | | | | | | | | As far as I can tell we were unnecessarily building a new TcgEnv when we already had one on hand. TcRnMonad now sports an initTcWithGbl function, which allows us to run a TcM monad in the context of this TcgEnv. This appears to simplify things nicely. Test Plan: Validate Reviewers: austin Subscribers: dfeuer, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3228
* DsMonad: Collect DPH thingsBen Gamari2017-03-071-137/+152
| | | | | | | | | | | | | This is just a bit of reorganization, pulling out the DPH things into a separate section of the file. Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3274
* Typos in changelog and commentsGabor Greif2017-03-071-1/+1
|
* Changed OverLit warnings to work with negative literals (#13257)Rupert Horlick2017-03-062-2/+12
| | | | | | | | | | | | Test Plan: Validate, check generated warnings Reviewers: austin, bgamari, dfeuer Reviewed By: bgamari, dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3281
* Read COMPLETE sets from external packagesBen Gamari2017-03-062-7/+18
| | | | | | | | | | | | | | | | | | | | | | Currently, `COMPLETE` pragmas are not read from external packages at all, which quite limits their usefulness. This extends `ExternalPackageState` to include `COMPLETE` sets from other packages, and plumbs around the appropriate values to make it work the way you'd expect it to. Requires a `binary` submodule update. Fixes #13350. Test Plan: make test TEST=T13350 Reviewers: rwbarton, mpickering, austin, simonpj, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3257
* Revert "Read COMPLETE sets from external packages"Ben Gamari2017-03-032-18/+7
| | | | This reverts commit 0d2f733050ff656b827351108d988e09abc363fc.
* Read COMPLETE sets from external packagesRyan Scott2017-03-022-7/+18
| | | | | | | | | | | | | | | | | | | | Currently, `COMPLETE` pragmas are not read from external packages at all, which quite limits their usefulness. This extends `ExternalPackageState` to include `COMPLETE` sets from other packages, and plumbs around the appropriate values to make it work the way you'd expect it to. Fixes #13350. Test Plan: make test TEST=T13350 Reviewers: rwbarton, mpickering, austin, simonpj, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3257
* Prohibit RULES changing constructorsDavid Feuer2017-03-021-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, `RULES` like ``` {-# RULES "JustNothing" forall x . Just x = Nothing #-} ``` were allowed. Simon Peyton Jones say this seems to have been a mistake, that such rules have never been supported intentionally, and that he doesn't know if they can break in horrible ways. Furthermore, Ben Gamari and Reid Barton are considering trying to detect the presence of "static data" that the simplifier doesn't need to traverse at all. Such rules do not play well with that. So for now, we ban them altogether. In most cases, it's possible to work around the ban using hand-written wrapper functions. Reviewers: austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3169
* Eliminate ListSetOps from imp_trust_pkgsDavid Feuer2017-03-022-11/+11
| | | | | | | | | | | | | | Eliminate ListSetOps from imp_trust_pkgs and imp_dep_pkgs Replace Map with NameEnv in TmOracle Reviewers: austin, dfeuer, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3113
* Upgrade UniqSet to a newtypeDavid Feuer2017-03-012-12/+13
| | | | | | | | | | | | | | | | | | | | | The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet` has a key invariant `UniqFM` does not. For example, `fmap` over `UniqSet` will generally produce nonsense. * Upgrade `UniqSet` from a type synonym to a newtype. * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`. * Use cached unique in `tyConsOfType` by replacing `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`. Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari Reviewed By: niteria Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3146
* Ensure that Literals are in rangeJoachim Breitner2017-02-262-32/+56
| | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes several bugs related to case expressions involving numeric literals which are not in the range of values of their (fixed-width, integral) type. There is a new invariant on Literal: The argument of a MachInt[64] or MachWord[64] must lie within the range of the corresponding primitive type Int[64]# or Word[64]#, as defined by the target machine. This invariant is enforced in mkMachInt[64]/mkMachWord[64] by wrapping the argument to the target type's range if necessary. Test Plan: Test Plan: make slowtest TEST="T9533 T9533b T9533c T10245 T10246" Trac issues: #9533, #10245, #10246, #13171 Reviewers: simonmar, simonpj, austin, bgamari, nomeata Reviewed By: bgamari Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D810
* Kill off the remaining Rec []Simon Peyton Jones2017-02-201-2/+2
| | | | | | | The desugarer was producing an empty Rec group, which is never supposed to happen. This small patch stops that happening. Next up: Lint should check.
* Type-indexed TypeableBen Gamari2017-02-181-41/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal.
* Fix recompilation tracking on signatures.Edward Z. Yang2017-02-171-5/+10
| | | | | | | | | | | | | | | | | | Summary: Previously we weren't tracking these dependencies at all, because we couldn't "find" the interface for {A.H}. Now we've associated hole names to the correct module identity so we will pick them up. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3131
* Make deSugarExpr use runTcInteractiveReid Barton2017-02-142-206/+219
| | | | | | | | | | | | | | | | | | | Preparation for #13102, which needs to add more logic to runTcInteractive, which would need to be duplicated in deSugarExpr. In order to break an import cycle, I had to move "Dependency/fingerprinting code" to a new module DsUsage; which seems sensible anyways. Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3125
* Implement HasField constraint solving and modify OverloadedLabelsAdam Gundry2017-02-145-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | This implements automatic constraint solving for the new HasField class and modifies the existing OverloadedLabels extension, as described in the GHC proposal (https://github.com/ghc-proposals/ghc-proposals/pull/6). Per the current form of the proposal, it does *not* currently introduce a separate `OverloadedRecordFields` extension. This replaces D1687. The users guide documentation still needs to be written, but I'll do that after the implementation is merged, in case there are further design changes. Test Plan: new and modified tests in overloadedrecflds Reviewers: simonpj, goldfire, dfeuer, bgamari, austin, hvr Reviewed By: bgamari Subscribers: maninalift, dfeuer, ysangkok, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2708
* Implement addCStub in template-haskell.Facundo Domínguez2017-02-091-1/+5
| | | | | | | | | | | | | | | | Summary: addCStub allows injecting C code in the current module to be included in the final object file. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: bgamari Subscribers: bitonic, duncan, mboes, thomie Differential Revision: https://phabricator.haskell.org/D3106
* Kill inaccessible-branch complaints in record updateSimon Peyton Jones2017-02-081-2/+26
| | | | | | | | | | Trac #12957 (the original case in the Description) showed a record update that yielded an "inaccessible code" warning. This should not happen; it's just some redundant code generated by the desugarer (later pruned away) and it's not the user's fault. This patch suppresses the warning. See Check.hs Note [Inaccessible warnings for record updates]
* More typos in comments [skip ci]Gabor Greif2017-02-082-2/+2
|
* Fix push_bang_into_newtype when the pattern match has no argumentsMatthew Pickering2017-02-071-9/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Correct behaviour of push_bang_into_newtype when the pattern match has no arguments. A user can write ``` newtype T = T Int f :: T -> () f !(T {}) = () ``` in which case we have to push the bang inwards through the newtype in order to achieve the desired strictness properties. This patch fixes this special case where the pattern match has no arguments to push the bang onto. We now make up a wildcard pattern which is wrapped in the bang pattern. ``` f (T !_) = () ``` Reviewers: simonpj, austin, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3057
* Typos in comments [skip ci]Gabor Greif2017-02-061-1/+1
|
* Don't return empty initial uncovered set for an unsat contextMatthew Pickering2017-02-051-7/+6
| | | | | | | | | | | | | | | | | | | | Previously when the checker encountered an unsatisfiable term of type context it would return an empty initial uncovered set. This caused all pattern matches in the context to be reported as redudant. This is arguably correct behaviour as they will never be reached but it is better to recover and provide accurate warnings for these cases to avoid error cascades. It would perhaps be better to report an error to the user about an inacessible branch but this is certainly better than many confusing redundant match warnings. Reviewers: gkaracha, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3064
* Ditch static flagsSylvain Henry2017-02-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove INLINE pragma on loopbreakerMatthew Pickering2017-02-021-1/+0
|
* Exhaustiveness check for EmptyCase (Trac #10746)George Karachalias2017-02-021-16/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Empty case expressions have strict semantics so the problem boils down to inhabitation checking for the type of the scrutinee. 3 main functions added: - pmTopNormaliseType_maybe for the normalisation of the scrutinee type - inhabitationCandidates for generating the possible patterns of the appropriate type - checkEmptyCase' to filter out the candidates that give rise to unsatisfiable constraints. See Note [Checking EmptyCase Expressions] in Check and Note [Type normalisation for EmptyCase] in FamInstEnv Test Plan: validate Reviewers: simonpj, goldfire, dfeuer, austin, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2105 GHC Trac Issues: #10746
* Introduce GHC.TypeNats module, change KnownNat evidence to be NaturalOleg Grenrus2017-02-011-1/+1
| | | | | | | | | | | | Reviewers: dfeuer, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3024 GHC Trac Issues: #13181
* Join pointsLuke Maurer2017-02-011-0/+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
* Template Haskell support for COMPLETE pragmasMatthew Pickering2017-01-261-1/+20
| | | | | | | | | | Reviewers: RyanGlScott, austin, goldfire, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2997 GHC Trac Issues: #13098
* COMPLETE pragmas for enhanced pattern exhaustiveness checkingMatthew Pickering2017-01-266-131/+256
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new pragma so that users can specify `COMPLETE` sets of `ConLike`s in order to sate the pattern match checker. A function which matches on all the patterns in a complete grouping will not cause the exhaustiveness checker to emit warnings. ``` pattern P :: () pattern P = () {-# COMPLETE P #-} foo P = () ``` This example would previously have caused the checker to warn that all cases were not matched even though matching on `P` is sufficient to make `foo` covering. With the addition of the pragma, the compiler will recognise that matching on `P` alone is enough and not emit any warnings. Reviewers: goldfire, gkaracha, alanz, austin, bgamari Reviewed By: alanz Subscribers: lelf, nomeata, gkaracha, thomie Differential Revision: https://phabricator.haskell.org/D2669 GHC Trac Issues: #8779
* Typos in comments [ci skip]Gabor Greif2017-01-251-1/+1
|
* Don't quantify implicit type variables when quoting type signatures in THRyan Scott2017-01-231-25/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A bug was introduced in GHC 8.0 in which Template Haskell-quoted type signatures would quantify _all_ their type variables, even the implicit ones. This would cause splices like this: ``` $([d| idProxy :: forall proxy (a :: k). proxy a -> proxy a idProxy x = x |]) ``` To splice back in something that was slightly different: ``` idProxy :: forall k proxy (a :: k). proxy a -> proxy a idProxy x = x ``` Notice that the kind variable `k` is now explicitly quantified! What's worse, this now requires the `TypeInType` extension to be enabled. This changes the behavior of Template Haskell quoting to never explicitly quantify type variables which are implicitly quantified in the source. There are some other places where this behavior pops up too, including class methods, type ascriptions, `SPECIALIZE` pragmas, foreign imports, and pattern synonynms (#13018), so I fixed those too. Fixes #13018 and #13123. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj, goldfire Subscribers: simonpj, mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2974 GHC Trac Issues: #13018, #13123
* Typos and grammar in manual/commentsGabor Greif2017-01-231-2/+2
|
* Update levity polymorphismRichard Eisenberg2017-01-1914-140/+464
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly.
* Spelling fixes in comments [ci skip]Gabor Greif2017-01-181-1/+1
|
* Typos in comments only [ci skip]Gabor Greif2017-01-181-1/+1
|
* Split mkInlineUnfolding into two functionsDavid Feuer2017-01-172-3/+4
| | | | | | | | | | | | | | | Previously, `mkInlineUnfolding` took a `Maybe` argument indicating whether the caller requested a specific arity. This was not self-documenting at call sites. Now we distinguish between `mkInlineUnfolding` and `mkInlineUnfoldingWithArity`. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2933
* Desugar static forms to makeStatic calls.Facundo Domínguez2017-01-131-57/+6
| | | | | | | | | | | | | | | | | | | Summary: Using makeStatic instead of applications of the StaticPtr data constructor makes possible linting core when unboxing strict fields. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari, hvr Reviewed By: simonpj Subscribers: RyanGlScott, mboes, thomie Differential Revision: https://phabricator.haskell.org/D2930 GHC Trac Issues: #12622
View Lorry Controller Status