summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
* Rip out object splittingBen Gamari2019-03-0519-325/+62
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
* Fix map/coerce rule for newtypes with wrappersKrzysztof Gogolewski2019-03-053-29/+32
| | | | | | | | This addresses Trac #16208 by marking newtype wrapper unfoldings as compulsory. Furthermore, we can remove the special case for newtypes in exprIsConApp_maybe (introduced in 7833cf407d1f).
* Be more careful when naming TyCon bindersSimon Peyton Jones2019-03-0510-356/+595
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes two rather gnarly test cases: * Trac #16342 (mutual recursion) See Note [Tricky scoping in generaliseTcTyCon] * Trac #16221 (shadowing) See Note [Unification variables need fresh Names] The main changes are: * Substantial reworking of TcTyClsDecls.generaliseTcTyCon This is the big change, and involves the rather tricky function TcHsSyn.zonkRecTyVarBndrs. See Note [Inferring kinds for type declarations] and Note [Tricky scoping in generaliseTcTyCon] for the details. * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now allocate /freshly-named/ unification variables. Indeed, more generally, unification variables are always fresh; see Note [Unification variables need fresh Names] in TcMType * Clarify the role of tcTyConScopedTyVars. See Note [Scoped tyvars in a TcTyCon] in TyCon As usual, this dragged in some more refactoring: * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise * I renamed checkValidTelescope to checkTyConTelescope; it's only used on TyCons, and indeed takes a TyCon as argument. * I folded the slightly-mysterious reportFloatingKvs into checkTyConTelescope. (Previously all its calls immediately followed a call to checkTyConTelescope.) It makes much more sense there. * I inlined some called-once functions to simplify checkValidTyFamEqn. It's less spaghetti-like now. * This patch also fixes Trac #16251. I'm not quite sure why #16251 went wrong in the first place, nor how this patch fixes it, but hey, it's good, and life is short.
* Revert "compiler: Write .o files atomically. See #14533"Ben Gamari2019-03-041-6/+1
| | | | This reverts commit 0e2d300a59b1b5c167d2e7d99a448c8663ba6d7d.
* Revert "compiler: Refactor: extract `withAtomicRename`"Ben Gamari2019-03-042-29/+8
| | | | This reverts commit e8a08f400744a860d1366c6680c8419d30f7cc2a.
* Lexer: turn some fatal errors into non-fatal onesAlec Theriault2019-03-011-18/+24
| | | | | | | | | | The following previously fatal lexer errors are now non-fatal: * errors about enabling `LambdaCase` * errors about enabling `NumericUnderscores` * errors about having valid characters in primitive strings See #16270
* Visible dependent quantificationRyan Scott2019-03-0122-136/+405
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements GHC proposal 35 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst) by adding the ability to write kinds with visible dependent quantification (VDQ). Most of the work for supporting VDQ was actually done _before_ this patch. That is, GHC has been able to reason about kinds with VDQ for some time, but it lacked the ability to let programmers directly write these kinds in the source syntax. This patch is primarly about exposing this ability, by: * Changing `HsForAllTy` to add an additional field of type `ForallVisFlag` to distinguish between invisible `forall`s (i.e, with dots) and visible `forall`s (i.e., with arrows) * Changing `Parser.y` accordingly The rest of the patch mostly concerns adding validity checking to ensure that VDQ is never used in the type of a term (as permitting this would require full-spectrum dependent types). This is accomplished by: * Adding a `vdqAllowed` predicate to `TcValidity`. * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy` that only splits invisible `forall`s. This function is used in certain places (e.g., in instance declarations) to ensure that GHC doesn't try to split visible `forall`s (e.g., if it tried splitting `instance forall a -> Show (Blah a)`, then GHC would mistakenly allow that declaration!) This also updates Template Haskell by introducing a new `ForallVisT` constructor to `Type`. Fixes #16326. Also fixes #15658 by documenting this feature in the users' guide.
* Treat kind/type variables identically, demolish FKTVVladislav Zavialov2019-02-278-481/+206
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error.
* base: Allow fusion for zip7 and relatedAlexandre2019-02-241-35/+75
| | | | | | | | | | | | | | | | | | Fixes #14037. Metric Decrease: T9872b T9872d Reviewers: bgamari, simonpj, hvr Reviewed By: simonpj Subscribers: AndreasK, simonpj, osa1, dfeuer, rwbarton, carter GHC Trac Issues: #14037 Differential Revision: https://phabricator.haskell.org/D5249
* Include closure header size in StgLamLift's estimationsSebastian Graf2019-02-231-4/+3
| | | | | | | | | | | While playing around with late lambda lifting, I realised that StgLamLift.Analysis doesn't consider the removed closure header in its allocation estimations. That's because contrary to what I thought, the total word count returned by `mkVirtHeapOffsets` doesn't include the size of the closure header. We just add the header size manually now.
* Fix regression incorrectly advertising TH supportHerbert Valerio Riedel2019-02-231-0/+8
| | | | | | | | `--supported-languages` must only advertise language extensions which are supported by the compiler in order for tooling such as Cabal relying on this signalling not to behave incorrectly. Fixes #16331
* Expression/command ambiguity resolutionVladislav Zavialov2019-02-238-344/+839
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by introducing a new ambiguity resolution system in the parser. Problem: there are places in the grammar where we do not know whether we are parsing an expression or a command: proc x -> do { (stuff) -< x } -- 'stuff' is an expression proc x -> do { (stuff) } -- 'stuff' is a command Until we encounter arrow syntax (-<) we don't know whether to parse 'stuff' as an expression or a command. The old solution was to parse as HsExpr always, and rejig later: checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs) This meant polluting 'HsExpr' with command-related constructors. In other words, limitations of the parser were affecting the AST, and all other code (the renamer, the typechecker) had to deal with these extra constructors by panicking. We fix this abstraction leak by parsing into an intermediate representation, 'ExpCmd': data ExpCmdG b where ExpG :: ExpCmdG HsExpr CmdG :: ExpCmdG HsCmd type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs)) checkExp :: ExpCmd -> PV (LHsExpr GhcPs) checkCmd :: ExpCmd -> PV (LHsCmd GhcPs) checkExp f = f ExpG -- interpret as an expression checkCmd f = f CmdG -- interpret as a command See Note [Ambiguous syntactic categories] for details. Now the intricacies of parsing have no effect on the hsSyn AST when it comes to the expression/command ambiguity. Future work: apply the same principles to the expression/pattern ambiguity.
* Add AnonArgFlag to FunTySimon Peyton Jones2019-02-2373-856/+1001
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big payload of this patch is: Add an AnonArgFlag to the FunTy constructor of Type, so that (FunTy VisArg t1 t2) means (t1 -> t2) (FunTy InvisArg t1 t2) means (t1 => t2) The big payoff is that we have a simple, local test to make when decomposing a type, leading to many fewer calls to isPredTy. To me the code seems a lot tidier, and probably more efficient (isPredTy has to take the kind of the type). See Note [Function types] in TyCoRep. There are lots of consequences * I made FunTy into a record, so that it'll be easier when we add a linearity field, something that is coming down the road. * Lots of code gets touched in a routine way, simply because it pattern matches on FunTy. * I wanted to make a pattern synonym for (FunTy2 arg res), which picks out just the argument and result type from the record. But alas the pattern-match overlap checker has a heart attack, and either reports false positives, or takes too long. In the end I gave up on pattern synonyms. There's some commented-out code in TyCoRep that shows what I wanted to do. * Much more clarity about predicate types, constraint types and (in particular) equality constraints in kinds. See TyCoRep Note [Types for coercions, predicates, and evidence] and Note [Constraints in kinds]. This made me realise that we need an AnonArgFlag on AnonTCB in a TyConBinder, something that was really plain wrong before. See TyCon Note [AnonTCB InivsArg] * When building function types we must know whether we need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy). This turned out to be pretty easy in practice. * Pretty-printing of types, esp in IfaceType, gets tidier, because we were already recording the (->) vs (=>) distinction in an ad-hoc way. Death to IfaceFunTy. * mkLamType needs to keep track of whether it is building (t1 -> t2) or (t1 => t2). See Type Note [mkLamType: dictionary arguments] Other minor stuff * Some tidy-up in validity checking involving constraints; Trac #16263
* Remove bogus assertionSimon Peyton Jones2019-02-231-1/+3
| | | | | | | Remove a bogus assertion in FamInst.newFamInst (There is a comment to explain.) This fixes Trac #16112.
* Fix exprIsConApp_maybeSimon Peyton Jones2019-02-224-55/+74
| | | | | | | | | | | | | | | | | | | In this commit commit 7833cf407d1f608bebb1d38bb99d3035d8d735e6 Date: Thu Jan 24 17:58:50 2019 +0100 Look through newtype wrappers (Trac #16254) we made exprIsConApp_maybe quite a bit cleverer. But I had not paid enough attention to keeping exactly the correct substitution and in-scope set, which led to Trac #16348. There were several buglets (like applying the substitution twice in exprIsConApp_maybe, but the proximate source of the bug was that we were calling addNewInScopeIds, which deleted things from the substitution as well as adding them to the in-scope set. That's usually right, but not here! This was quite tricky to track down. But it is nicer now.
* Don't do binder-swap for GlobalIdsSimon Peyton Jones2019-02-221-3/+8
| | | | | | | | | | | | This patch disables the binder-swap transformation in the (relatively rare) case when the scrutinee is a GlobalId. Reason: we are getting Lint errors so that GHC doesn't even validate. Trac #16346. This is NOT the final solution -- it's just a stop-gap to get us running again. The final solution is in Trac #16296
* Remove tcTyConUserTyVarsSimon Peyton Jones2019-02-223-15/+10
| | | | | | The tcTyConUserTyVars field of TcTyCon was entirely unused. This patch kills it off entirely.
* compiler: Refactor: extract `withAtomicRename`Niklas Hambüchen2019-02-212-8/+29
|
* compiler: Write .o files atomically. See #14533Niklas Hambüchen2019-02-211-1/+6
| | | | | | | | | | | | | | | | | | | This issue was reproduced with, and the fix confirmed with, the `hatrace` tool for syscall-based fault injection: https://github.com/nh2/hatrace The concrete test case for GHC is at https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185 A previous, nondeterministic reproducer for the issue was provided by Alexey Kuleshevich in https://github.com/lehins/exec-kill-loop Signed-off-by: Niklas Hambüchen <niklas@fpcomplete.com> Reviewed-by: Alexey Kuleshevich <alexey@fpcomplete.com>
* Handle the (~) type operator in 'tyconsym'Vladislav Zavialov2019-02-212-8/+8
| | | | | By parsing '~' in 'tyconsym' instead of 'oqtycon', we get one less shift/reduce conflict.
* Dot/bang operators in export lists (Trac #16339)Vladislav Zavialov2019-02-212-5/+10
| | | | | | | | The dot type operator was handled in the 'tyvarop' parser production, and the bang type operator in 'tyapp'. However, export lists and role annotations use 'oqtycon', so these type operators could not be exported or assigned roles. The fix is to handle them in a lower level production, 'tyconsym'.
* Comments only, in GhcPreludeSimon Peyton Jones2019-02-201-1/+5
|
* Improve the very simple optimiser slightlySimon Peyton Jones2019-02-201-0/+10
| | | | | | | | | There was a missing case in the very simple optimiser, CoreOpt.simpleOptExpr, which led to Trac #13208 comment:2. In particular, in simple_app, if we find a Let, we should just float it outwards. Otherwise we leave behind some easy-to-reduce beta-redexes.
* Tiny refactor in isUnliftedRuntimeRepSimon Peyton Jones2019-02-201-11/+17
| | | | No change in behaviour, slightly more efficient
* Look through newtype wrappers (Trac #16254)Krzysztof Gogolewski2019-02-193-8/+60
| | | | | | exprIsConApp_maybe could detect that I# 10 is a constructor application, but not that Size (I# 10) is, because it was an application with a nontrivial argument.
* Make constructor wrappers inline only during the final phaseArnaud Spiwack2019-02-197-56/+247
| | | | | | | For case-of-known constructor to continue triggering early, exprIsConApp_maybe is now capable of looking through lets and cases. See #15840
* Disable binder swap in OccurAnal (Trac #16288)Krzysztof Gogolewski2019-02-191-5/+38
|
* Uphold AvailTC Invariant for associated data famsAlec Theriault2019-02-182-26/+68
| | | | | | | | | | | | | | | | | | | | The AvailTC was not be upheld for explicit export module export lists when the module contains associated data families. module A (module A) where class C a where { data T a } instance C () where { data T () = D } Used to (incorrectly) report avails as `[C{C, T;}, T{D;}]`. Note that although `T` is exported, the avail where it is the parent does _not_ list it as its first element. This avail is now correctly listed as `[C{C, T;}, T{T, D;}]`. This was induces a [crash in Haddock][0]. See #16077. [0]: https://github.com/haskell/haddock/issues/979
* Fix warnings and fatal parsing errorsVladislav Zavialov2019-02-1712-129/+145
|
* Get rid of tcm_smart from TyCoMapperSimon Peyton Jones2019-02-174-55/+39
| | | | | | | | | | | | | | | Following a succession of refactorings of the type checker, culminating in the patch Make a smart mkAppTyM we have got rid of mkNakedAppTy etc. And that in turn meant that the tcm_smart field of the generic TyCoMapper (in Type.hs) was entirely unused. It was always set to True. So this patch just gets rid of it completely. Less code, less complexity, and more efficient because fewer higher-order function calls. Everyone wins. No change in behaviour; this does not cure any bugs!
* Cmm: Promote stack arguments to word sizePeter Trommler2019-02-161-7/+29
| | | | | | | | | | | | | | | | | Smaller than word size integers must be promoted to word size when passed on the stack. While on little endian systems we can get away with writing a small integer to a word size stack slot and read it as a word ignoring the upper bits, on big endian systems a small integer write ends up in the most significant bits and a word size read that ignores the upper bits delivers a random value. On little endian systems a smaller than word size write to the stack might be more efficient but that decision is system specific and should be done as an optimization in the respective backends. Fixes #16258
* HIE: Save module name and module exportsMatthew Pickering2019-02-163-5/+25
|
* Don't wrap the entry map for LiveInfo in Maybe.klebinger.andreas@gmx.at2019-02-156-26/+27
| | | | | | | | | | | | | It never really encoded a invariant. * The linear register allocator just did partial pattern matches * The graph allocator just set it to (Just mapEmpty) for Nothing So I changed LiveInfo to directly contain the map. Further natCmmTopToLive which filled in Nothing is no longer exported. Instead we know call cmmTopLiveness which changes the type AND fills in the map.
* Properly escape character literals in HaddocksAlec Theriault2019-02-152-5/+5
| | | | | | | | Character literals in Haddock should not be written as plain `'\n'` since single quotes are for linking identifiers. Besides, since we want the character literal to be monospaced, we really should use `@\'\\n\'@`. [skip ci]
* 'forall' always a keyword, plus the dot type operatorVladislav Zavialov2019-02-156-64/+41
|
* Fail fast in solveLocalEqualitiesSimon Peyton Jones2019-02-142-1/+22
| | | | | | | | | | | | | | | | | | This patch makes us fail fast in TcSimplify.solveLocalEqualities, and in TcHsType.tc_hs_sig_type, if there are insoluble constraints. Previously we ploughed on even if there were insoluble constraints, leading to a cascade of hard-to-understand type errors. Failing eagerly is much better; hence a lot of testsuite error message changes. Eg if we have f :: [Maybe] -> blah f xs = e then trying typecheck 'f x = e' with an utterly bogus type is just asking for trouble. I can't quite remember what provoked me to make this change, but I think the error messages are notably improved, by removing confusing clutter and focusing on the real error.
* Make a smart mkAppTyMSimon Peyton Jones2019-02-1424-756/+830
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch finally delivers on Trac #15952. Specifically * Completely remove Note [The tcType invariant], along with its complicated consequences (IT1-IT6). * Replace Note [The well-kinded type invariant] with: Note [The Purely Kinded Type Invariant (PKTI)] * Instead, establish the (PKTI) in TcHsType.tcInferApps, by using a new function mkAppTyM when building a type application. See Note [mkAppTyM]. * As a result we can remove the delicate mkNakedXX functions entirely. Specifically, mkNakedCastTy retained lots of extremly delicate Refl coercions which just cluttered everything up, and(worse) were very vulnerable to being silently eliminated by (say) substTy. This led to a succession of bug reports. The result is noticeably simpler to explain, simpler to code, and Richard and I are much more confident that it is correct. It does not actually fix any bugs, but it brings us closer. E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite do so. However, it makes it much easier to fix. I also did a raft of other minor refactorings: * Use tcTypeKind consistently in the type checker * Rename tcInstTyBinders to tcInvisibleTyBinders, and refactor it a bit * Refactor tcEqType, pickyEqType, tcEqTypeVis Simpler, probably more efficient. * Make zonkTcType zonk TcTyCons, at least if they have any free unification variables -- see zonk_tc_tycon in TcMType.zonkTcTypeMapper. Not zonking these TcTyCons was actually a bug before. * Simplify try_to_reduce_no_cache in TcFlatten (a lot) * Combine checkExpectedKind and checkExpectedKindX. And then combine the invisible-binder instantation code Much simpler now. * Fix a little bug in TcMType.skolemiseQuantifiedTyVar. I'm not sure how I came across this originally. * Fix a little bug in TyCoRep.isUnliftedRuntimeRep (the ASSERT was over-zealous). Again I'm not certain how I encountered this. * Add a missing solveLocalEqualities in TcHsType.tcHsPartialSigType. I came across this when trying to get level numbers right.
* Implement -Wredundant-record-wildcards and -Wunused-record-wildcardsMatthew Pickering2019-02-1410-54/+175
| | | | | | | | | -Wredundant-record-wildcards warns when a .. pattern binds no variables. -Wunused-record-wildcards warns when none of the variables bound by a .. pattern are used. These flags are enabled by `-Wall`.
* NCG: fast compilation of very large strings (#16190)Sylvain Henry2019-02-145-12/+57
| | | | | | | | | | This patch adds an optimization into the NCG: for large strings (threshold configurable via -fbinary-blob-threshold=NNN flag), instead of printing `.asciz "..."` in the generated ASM source, we print `.incbin "tmpXXX.dat"` and we dump the contents of the string into a temporary "tmpXXX.dat" file. See the note for more details.
* Fix #15849 by checking whether there's a do blocknineonine2019-02-121-1/+2
|
* Fix #16299 by deleting incorrect code from IfaceSynRyan Scott2019-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | GHCi's `:info` command was pretty-printing Haskell98-style data types with explicit return kinds if the return kind wasn't `Type`. This leads to bizarre output like this: ``` λ> :i (##) data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##) -- Defined in ‘GHC.Prim’ ``` Or, with unlifted newtypes: ``` λ> newtype T = MkT Int# λ> :i T newtype T :: TYPE 'IntRep = MkT Int# -- Defined at <interactive>:5:1 ``` The solution is simple: just delete one part from `IfaceSyn` where GHC mistakenly pretty-prints the return kinds for non-GADTs.
* Fix #16188Richard Eisenberg2019-02-122-14/+29
| | | | | | | | | | | | | | There was an awful lot of zipping going on in canDecomposableTyConAppOK, and one of the lists being zipped was too short, causing the result to be too short. Easily fixed. Also fixes #16204 and #16225 test case: typecheck/should_compile/T16188 typecheck/should_compile/T16204[ab] typecheck/should_fail/T16204c typecheck/should_compile/T16225
* Fix #16293 by cleaning up Proxy# infelicitiesRyan Scott2019-02-124-19/+30
| | | | | | | | | | | | | | | | | | | | This bug fixes three problems related to `Proxy#`/`proxy#`: 1. Reifying it with TH claims that the `Proxy#` type constructor has two arguments, but that ought to be one for consistency with TH's treatment for other primitive type constructors like `(->)`. This was fixed by just returning the number of `tyConVisibleTyVars` instead of using `tyConArity` (which includes invisible arguments). 2. The role of `Proxy#`'s visible argument was hard-coded as nominal. Easily fixed by changing it to phantom. 3. The visibility of `proxy#`'s kind argument was specified, which is different from the `Proxy` constructor (which treats it as inferred). Some minor refactoring in `proxyHashId` fixed ths up. Along the way, I had to introduce a `mkSpecForAllTy` function, so I did some related Haddock cleanup in `Type`, where that function lives.
* Fix Int overflow on 32 bit platformPeter Trommler2019-02-101-1/+1
|
* Capture and simplify constraints arising from running typed splicesMatthew Pickering2019-02-101-3/+8
| | | | | | | | | | | | | | | This fixes a regression caused by #15471 where splicing in a trivial program such as `[|| return () ||]` would fail as the dictionary for `return` would never get bound in the module containing the splice. Arguably this is symptomatic of a major problem affecting TTH where we serialise renamed asts and then retype check them. The reference to the dictionary should be fully determined at the quote site so that splicing doesn't have to solve any implicits at all. It's a coincidence this works due to coherence but see #15863 and #15865 for examples where things do go very wrong. Fixes #16195
* Remove ghctags (#16274)Sylvain Henry2019-02-101-3/+0
|
* Fix inverted position pragma flag in parser APIAlec Theriault2019-02-101-1/+1
| | | | | | | | The behviour of `lexTokenStream` around position pragma was accidentally inverted in 469fe6133646df5568c9486de2202124cb734242. This fixes that bug. This also unbreaks #16239.
* Improve snocView implementation.klebinger.andreas@gmx.at2019-02-091-12/+17
| | | | | | | | | | | | The new implementation isn't tailrecursive and instead builds up the initial part of the list as it goes. This improves allocation numbers as we don't build up an intermediate list just to reverse it later. This is slightly slower for lists of size <= 3. But in benchmarks significantly faster for any list above 5 elements, assuming the majority of the resulting list will be evaluated.
* Replace a few uses of snocView with last/lastMaybe.klebinger.andreas@gmx.at2019-02-093-4/+13
| | | | | | These never used the first part of the result from snocView. Hence replacing them with last[Maybe] is both clearer and gives better performance.
* Stack: fix name mangling.Tamar Christina2019-02-091-1/+1
|
View Lorry Controller Status