summaryrefslogtreecommitdiff
path: root/testsuite/tests
Commit message (Collapse)AuthorAgeFilesLines
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-15247-256/+256
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Remove the GHCi debugger's panicking isUnliftedType checkRyan Scott2019-03-153-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GHCi debugger has never been that robust in the face of higher-rank types, or even types that are _interally_ higher-rank, such as the types of many class methods (e.g., `fmap`). In GHC 8.2, however, things became even worse, as the debugger would start to _panic_ when a user tries passing the name of a higher-rank thing to `:print`. This all ties back to a strange `isUnliftedType` check in `Debugger` that was mysteriously added 11 years ago (in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no explanation whatsoever. After some experimentation, no one is quite sure what this `isUnliftedType` check is actually accomplishing. The test suite still passes if it's removed, and I am unable to observe any differences in debugger before even with data types that _do_ have fields of unlifted types (e.g., `data T = MkT Int#`). Given that this is actively causing problems (see #14828), the prudent thing to do seems to be just removing this `isUnliftedType` check, and waiting to see if anyone shouts about it. This patch accomplishes just that. Note that this patch fix the underlying issues behind #14828, as the debugger will still print unhelpful info if you try this: ``` λ> f :: (forall a. a -> a) -> b -> b; f g x = g x λ> :print f f = (_t1::t1) ``` But fixing this will require much more work, so let's start with the simple stuff for now.
* testsuite: Add testcase for #16394Ben Gamari2019-03-143-0/+18
|
* Fix #16411 by making dataConCannotMatch aware of (~~)Ryan Scott2019-03-132-0/+15
| | | | | | | | The `dataConCannotMatch` function (which powers the `-Wpartial-fields` warning, among other things) had special reasoning for explicit equality constraints of the form `a ~ b`, but it did not extend that reasoning to `a ~~ b` constraints, leading to #16411. Easily fixed.
* testsuite: Mark heapprof001 as fragile on all platformsBen Gamari2019-03-131-1/+1
| | | | See #15382.
* Add regression test for #16347Ryan Scott2019-03-122-1/+9
| | | | | | Commit 1f5cc9dc8aeeafa439d6d12c3c4565ada524b926 ended up fixing #16347. Let's add a regression test to ensure that it stays fixed.
* Use transSuperClasses in TcErrorsSimon Peyton Jones2019-03-123-0/+31
| | | | | | | | | | Code in TcErrors was recursively using immSuperClasses, which loops in the presence of UndecidableSuperClasses. Better to use transSuperClasses instead, which has a loop-breaker mechanism built in. Fixes issue #16414.
* Add a test for Trac #13951Krzysztof Gogolewski2019-03-112-0/+20
| | | | It no longer gives a warning.
* Ignore more version numbers in the testsuiteAlec Theriault2019-03-1115-18/+25
| | | | | | | | | Prevents some tests from failing just due to mismatched version numbers. These version numbers shouldn't cause tests to fail, especially since we *expect* them to be regularly incremented. The motivation for this particular set of changes came from the changes that came along with the `base` version bump in 8f19ecc95fbaf2cc977531d721085d8441dc09b7.
* Make bkpcabal01 test compatible with new ordering requirements.Edward Z. Yang2019-03-091-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, our test did something like this: 1. Typecheck p 2. Typecheck q (which made use of an instantiated p) 3. Build instantiated p 4. Build instantiated q Cabal previously permitted this, under the reasoning that during typechecking there's no harm in using the instantiated p even if we haven't build it yet; we'll just instantiate it on the fly with p. However, this is not true! If q makes use of a Template Haskell splice from p, we absolutely must have built the instantiated p before we typecheck q, since this typechecking will need to run some splices. Cabal now complains that you haven't done it correctly, which we indeed have not! Reordering so that we do this: 1. Typecheck p 3. Build instantiated p 2. Typecheck q (which made use of an instantiated p) 4. Build instantiated q Fixes the problem. If Cabal had managed the ordering itself, it would have gotten it right. Signed-off-by: Edward Z. Yang <ezyang@fb.com>
* Stop inferring over-polymorphic kindsSimon Peyton Jones2019-03-0912-38/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch GHC was trying to be too clever (Trac #16344); it succeeded in kind-checking this polymorphic-recursive declaration data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) As Note [No polymorphic recursion] discusses, the "solution" was horribly fragile. So this patch deletes the key lines in TcHsType, and a wodge of supporting stuff in the renamer. There were two regressions, both the same: a closed type family decl like this (T12785b) does not have a CUSK: type family Payload (n :: Peano) (s :: HTree n x) where Payload Z (Point a) = a Payload (S n) (a `Branch` stru) = a To kind-check the equations we need a dependent kind for Payload, and we don't get that any more. Solution: make it a CUSK by giving the result kind -- probably a good thing anyway. The other case (T12442) was very similar: a close type family declaration without a CUSK.
* Fix #13839: GHCi warnings do not respect the default module headerwip/magic-carpet-rideRoland Senn2019-03-089-0/+48
|
* TH: support raw bytes literals (#14741)Sylvain Henry2019-03-083-0/+30
| | | | | | | | | | | | | | | | | | | GHC represents String literals as ByteString internally for efficiency reasons. However, until now it wasn't possible to efficiently create large string literals with TH (e.g. to embed a file in a binary, cf #14741): TH code had to unpack the bytes into a [Word8] that GHC then had to re-pack into a ByteString. This patch adds the possibility to efficiently create a "string" literal from raw bytes. We get the following compile times for different sizes of TH created literals: || Size || Before || After || Gain || || 30K || 2.307s || 2.299 || 0% || || 3M || 3.073s || 2.400s || 21% || || 30M || 8.517s || 3.390s || 60% || Ticket #14741 can be fixed if the original code uses this new TH feature.
* Use captureTopConstraints in TcRnDriver callsSimon Peyton Jones2019-03-084-0/+19
| | | | | | | | | | | | | | | | | Trac #16376 showed the danger of failing to report an error that exists only in the unsolved constraints, if an exception is raised (via failM). Well, the commit 5c1f268e (Fail fast in solveLocalEqualities) did just that -- i.e. it found errors in the constraints, and called failM to avoid a misleading cascade. So we need to be sure to call captureTopConstraints to report those insolubles. This was wrong in TcRnDriver.tcRnExpr and in TcRnDriver.tcRnType. As a result the error messages from test T13466 improved slightly, a happy outcome.
* Testsuite: use 'fragile' instead of 'skip' for T3424, T14697Vladislav Zavialov2019-03-082-13/+10
| | | | | Also, replace some tabs with spaces to avoid a "mixed indent" warning that vim gives me.
* Always do the worker/wrapper split for NOINLINEsSebastian Graf2019-03-079-22/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #10069 revealed that small NOINLINE functions didn't get split into worker and wrapper. This was due to `certainlyWillInline` saying that any unfoldings with a guidance of `UnfWhen` inline unconditionally. That isn't the case for NOINLINE functions, so we catch this case earlier now. Nofib results: -------------------------------------------------------------------------------- Program Allocs Instrs -------------------------------------------------------------------------------- fannkuch-redux -0.3% 0.0% gg +0.0% +0.1% maillist -0.2% -0.2% minimax 0.0% -0.8% -------------------------------------------------------------------------------- Min -0.3% -0.8% Max +0.0% +0.1% Geometric Mean -0.0% -0.0% Fixes #10069. ------------------------- Metric Increase: T9233 -------------------------
* Fix #16391 by using occCheckExpand in TcValidityRyan Scott2019-03-077-8/+43
| | | | | | | | | | | | | The type-variables-escaping-their-scope-via-kinds check in `TcValidity` was failing to properly expand type synonyms, which led to #16391. This is easily fixed by using `occCheckExpand` before performing the validity check. Along the way, I refactored this check out into its own function, and sprinkled references to Notes to better explain all of the moving parts. Many thanks to @simonpj for the suggestions. Bumps the haddock submodule.
* Fix #16392: revertCAFs in external interpreter when necessaryPhuong Trinh2019-03-075-0/+24
| | | | | | | | | We revert CAFs when loading/adding modules in ghci (presumably to refresh execution states and to allow for object code to be unloaded from the runtime). However, with `-fexternal-interpreter` enabled, we are only doing it in the ghci process instead of the external interpreter process where the cafs are allocated and computed. This makes sure that revertCAFs is done in the appropriate process no matter if that flag is present or not.
* Test Trac #16263Simon Peyton Jones2019-03-063-0/+10
|
* Add tests for Trac #16221 and #16342Simon Peyton Jones2019-03-065-0/+42
|
* testsuite: Use fragile modifier for more testsBen Gamari2019-03-065-18/+9
|
* testsuite: Mark heapprof001 as fragile on i386Ben Gamari2019-03-061-1/+1
|
* Fix #16385 by appending _maybe to a use of lookupGlobalOccRyan Scott2019-03-063-0/+14
| | | | | | | | | `instance forall c. c` claimed that `c` was out of scope because the renamer was invoking `lookupGlobalOcc` on `c` (in `RnNames.getLocalNonValBinders`) without binding `c` first. To avoid this, this patch changes GHC to invoke `lookupGlobalOcc_maybe` on `c` instead, and if that returns `Nothing`, then bail out, resulting in a better error message.
* Add regression test for #15918Ryan Scott2019-03-053-0/+27
| | | | | | | | The test case in #15918 no longer triggers an `ASSERT` failure on GHC HEAD, likely due to commit 682783828275cca5fd8bf5be5b52054c75e0e22c (`Make a smart mkAppTyM`). This patch adds a regression test for #15918 to finally put it to rest.
* Fix map/coerce rule for newtypes with wrappersKrzysztof Gogolewski2019-03-053-0/+19
| | | | | | | | 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-053-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Don't leave .hi files after running Haddock testsAlec Theriault2019-03-041-0/+4
| | | | | | RyanGlScott observed in https://github.com/haskell/haddock/issues/1030 that running Haddock tests in GHC's testsuite left some `.hi` files around in `utils/haddock`. This should fix that problem.
* testsuite: Suppress ticks when comparing -ddump-simpl outputBen Gamari2019-03-013-26/+26
| | | | | Otherwise these tests break spuriously when core libraries are compiled with source notes.
* Lexer: turn some fatal errors into non-fatal onesAlec Theriault2019-03-013-3/+18
| | | | | | | | | | 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-0133-6/+317
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Cleanup iserv/iserv-proxyMoritz Angermann2019-02-2810-0/+83
| | | | | | | | | | | | This adds trace messages that include the processes name and as such make debugging and following the communication easier. It also adds a note regarding the fwd*Call proxy-communication logic between the proxy and the slave. The proxy will now also poll for 60s to wait for the remote iserv to come up. (Alternatively you can start the remote process beforehand; and just have iserv-proxy connect to it)
* Fix intermittent hie002 failureVladislav Zavialov2019-02-271-1/+2
| | | | | | | | | | | | | | | | | | | | | | hie002 is a performance test that used to fail unpredictably: max_bytes_used Decrease from x86_64-linux-deb9-debug baseline @ HEAD~2: Expected hie002 (normal) max_bytes_used: 1190923992.0 +/-20% Lower bound hie002 (normal) max_bytes_used: 952739193 Upper bound hie002 (normal) max_bytes_used: 1429108791 Actual hie002 (normal) max_bytes_used: 726270784 Deviation hie002 (normal) max_bytes_used: -39.0 % peak_megabytes_allocated Decrease from x86_64-linux-deb9-debug baseline @ HEAD~2: Expected hie002 (normal) peak_megabytes_allocated: 2538.0 +/-20% Lower bound hie002 (normal) peak_megabytes_allocated: 2030 Upper bound hie002 (normal) peak_megabytes_allocated: 3046 Actual hie002 (normal) peak_megabytes_allocated: 1587 Deviation hie002 (normal) peak_megabytes_allocated: -37.5 % *** unexpected stat test failure for hie002(normal) 'max_bytes_used' and 'peak_megabytes_allocated' are too unstable without careful control of the runtime configuration. We fix this by using a more predictable metric, 'bytes allocated'.
* RTS: Add missing memory barrierPeter Trommler2019-02-271-3/+6
| | | | | | | | | | | | | In the work stealing queue a load-load-barrier is required to ensure that a read of queue data cannot be reordered before a read of the bottom pointer into the queue. The added load-load-barrier ensures that the ordering of writes enforced at the end of `pushWSDeque` is also respected in the order of reads in `stealWSDeque_`. In other words, when reading `q->bottom` we want to make sure that we see the updates to `q->elements`. Fixes #13633
* Treat kind/type variables identically, demolish FKTVVladislav Zavialov2019-02-2748-113/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Skip T3424 when fast()wip/test-t3424Vladislav Zavialov2019-02-261-0/+1
| | | | 14586f5d removed this by accident.
* Fix the ghci063 test on Darwin (Trac #16201)wip/trac-16201Vladislav Zavialov2019-02-252-1/+13
| | | | | | | | | | | | | We use "touch -r" to set modification timestamps, which leads to precision loss on Darwin. For example, before: 2019-02-25 01:11:23.807627350 +0300 after: 2019-02-25 01:11:23.807627000 +0300 ^^^ This means we can't trick GHCi into thinking the file hasn't been changed by restoring its old timestamp, as we cannot faithfully restore all digits. The solution is to nullify the insignificant digits before the first :load
* Disable fragile test cases: T14697 T5559 T3424Vladislav Zavialov2019-02-243-6/+15
| | | | See Trac #15072, Trac #16349, Trac #16350
* Exit with exit code 1 when tests unexpectedly passMatthew Pickering2019-02-231-2/+8
| | | | | | This was causing gitlab to not report from builds as failing. It also highlighted a problem with the LLVM tests where some of the external interpreter tests are failing.
* Expression/command ambiguity resolutionVladislav Zavialov2019-02-231-3/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-237-21/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix exprIsConApp_maybeSimon Peyton Jones2019-02-222-0/+7
| | | | | | | | | | | | | | | | | | | 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.
* Dot/bang operators in export lists (Trac #16339)Vladislav Zavialov2019-02-212-0/+19
| | | | | | | | 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'.
* Improve the very simple optimiser slightlySimon Peyton Jones2019-02-204-0/+11
| | | | | | | | | 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.
* Test bit-manipulating primops under respective arch flags like -msse4.2Dmitry Ivanov2019-02-203-1/+121
|
* Bump ghc version to 8.9Ryan Scott2019-02-201-4/+4
| | | | | | | Along the way, I discovered that `template-haskell.cabal` was hard-coding the GHC version (in the form of its `ghc-boot-th` version bounds), so I decided to make life a little simpler in the future by generating `template-haskell.cabal` with autoconf.
* Look through newtype wrappers (Trac #16254)Krzysztof Gogolewski2019-02-194-0/+21
| | | | | | 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-5/+42
| | | | | | | 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-195-2/+40
|
* Fix warnings and fatal parsing errorsVladislav Zavialov2019-02-179-27/+100
|
* Run some of Haddock's tests in the testsuiteAlec Theriault2019-02-162-0/+89
| | | | | | | | The 4 main testsuites in Haddock don't have many dependencies, but are regularly broken in small ways by changes to the GHC AST or the GHC API. The main gotcha is that we'll have to make sure that `haddock-test` and the test suite don't add modules without modifying this test. Then again, if that happens, the test will fail and someone will noticed.
View Lorry Controller Status