summaryrefslogtreecommitdiff
path: root/testsuite/tests
Commit message (Collapse)AuthorAgeFilesLines
* Track type variable scope more carefully.Richard Eisenberg2018-03-3180-399/+889
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main job of this commit is to track more accurately the scope of tyvars introduced by user-written foralls. For example, it would be to have something like this: forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool In that type, a's kind must be k, but k isn't in scope. We had a terrible way of doing this before (not worth repeating or describing here, but see the old tcImplicitTKBndrs and friends), but now we have a principled approach: make an Implication when kind-checking a forall. Doing so then hooks into the existing machinery for preventing skolem-escape, performing floating, etc. This also means that we bump the TcLevel whenever going into a forall. The new behavior is done in TcHsType.scopeTyVars, but see also TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant rewriting. There are several Notes near there to guide you. Of particular interest there is that Implication constraints can now have skolems that are out of order; this situation is reported in TcErrors. A major consequence of this is a slightly tweaked process for type- checking type declarations. The new Note [Use SigTvs in kind-checking pass] in TcTyClsDecls lays it out. The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142. Other minor changes: - isUnliftedTypeKind didn't look for tuples and sums. It does now. - check_type used check_arg_type on both sides of an AppTy. But the left side of an AppTy isn't an arg, and this was causing a bad error message. I've changed it to use check_type on the left-hand side. - Some refactoring around when we print (TYPE blah) in error messages. The changes decrease the times when we do so, to good effect. Of course, this is still all controlled by -fprint-explicit-runtime-reps Fixes #14066 #14749 Test cases: dependent/should_compile/{T14066a,T14749}, dependent/should_fail/T14066{,c,d,e,f,g,h}
* testsuite: Add test for #14965Ben Gamari2018-03-274-0/+30
|
* Fix the test for #13938Ryan Scott2018-03-274-68/+102
| | | | | Only half of the test files were checked in for T13938. This commit adds the missing half.
* Fix performance of flattener patch (#12919)Alexander Vieth2018-03-262-8/+8
| | | | | | | | | | | This patch, authored by alexvieth and reviewed at D4451, makes performance improvements by critically optimizing parts of the flattener. Summary: T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass. T9872a and T9872c show improvements beyond the -5% threshold. T9872d fails at 10.9% increased allocations.
* Fix #12919 by making the flattener homegeneous.Richard Eisenberg2018-03-2612-25/+230
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This changes a key invariant of the flattener. Previously, flattening a type meant flattening its kind as well. But now, flattening is always homogeneous -- that is, the kind of the flattened type is the same as the kind of the input type. This is achieved by various wizardry in the TcFlatten.flatten_many function, as described in Note [flatten_many]. There are several knock-on effects, including some refactoring in the canonicalizer to take proper advantage of the flattener's changed behavior. In particular, the tyvar case of can_eq_nc' no longer needs to take casts into account. Another effect is that flattening a tyconapp might change it into a casted tyconapp. This might happen if the result kind of the tycon contains a variable, and that variable changes during flattening. Because the flattener is homogeneous, it tacks on a cast to keep the tyconapp kind the same. However, this is problematic when flattening CFunEqCans, which need to have an uncasted tyconapp on the LHS and must remain homogeneous. The solution is a more involved canCFunEqCan, described in Note [canCFunEqCan]. This patch fixes #13643 (as tested in typecheck/should_compile/T13643) and the panic in typecheck/should_compile/T13822 (as reported in #14024). Actually, there were two bugs in T13822: the first was just some incorrect logic in tryFill (part of the unflattener) -- also fixed in this patch -- and the other was the main bug fixed in this ticket. The changes in this patch exposed a long-standing flaw in OptCoercion, in that breaking apart an AppCo sometimes has unexpected effects on kinds. See new Note [EtaAppCo] in OptCoercion, which explains the problem and fix. Also here is a reversion of the major change in 09bf135ace55ce2572bf4168124d631e386c64bb, affecting ctEvCoercion. It turns out that making the flattener homogeneous changes the invariants on the algorithm, making the change in that patch no longer necessary. This patch also fixes: #14038 (dependent/should_compile/T14038) #13910 (dependent/should_compile/T13910) #13938 (dependent/should_compile/T13938) #14441 (typecheck/should_compile/T14441) #14556 (dependent/should_compile/T14556) #14720 (dependent/should_compile/T14720) #14749 (typecheck/should_compile/T14749) Sadly, this patch negatively affects performance of type-family- heavy code. The following patch fixes these performance degradations. However, the performance fixes are somewhat invasive and so I've kept them as a separate patch, labeling this one as [skip ci] so that validation doesn't fail on the performance cases.
* Add unaligned bytearray access primops. Fixes #4442.Reiner Pope2018-03-253-1/+280
| | | | | | | | | | | | Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: dfeuer, rwbarton, thomie, carter GHC Trac Issues: #4442 Differential Revision: https://phabricator.haskell.org/D4488
* Add new debugging flag -dinline-checkBen Gamari2018-03-253-0/+39
| | | | | | | | | | | | | | | | | | | | | | | This flag reports a summary of the inlining decision for identifiers prefixed by the flag's argument. For example, `-dinline-check foo` will report why definitions whose prefix is `foo` are inlined or not. Previously the only way to get this information was to pass a combination of `-dverbose-core2core` and `-ddump-inlinings`. This combination led to a log of 12 million lines in a module of about 200 lines I recently had to apply it to. This flag provides a much more direct way to find the occurence you care about. Reviewers: osa1, dfeuer, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4458
* Fix scoped type variables in TH for several constructsHE, Tao2018-03-255-2/+53
| | | | | | | | | | | | | | | | | | | | | | | | Namely class methods, default signatures and pattern synonyms. When scoped type variables occur inside class default methods, default signatures and pattern synonyms, avoid re-create explicit type variables when represent the type signatures. This patch should fix Trac#14885. Signed-off-by: HE, Tao <sighingnow@gmail.com> Test Plan: make test TEST="T14885a T14885b T14885c" Reviewers: goldfire, bgamari, simonpj, RyanGlScott Reviewed By: simonpj, RyanGlScott Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14885 Differential Revision: https://phabricator.haskell.org/D4469
* Don't refer to blocks in debug info when -g1Bartosz Nitka2018-03-253-0/+11
| | | | | | | | | | | | | | | | | | | | -g1 removes block information, but it turns out that procs can refer to block information through parents. Note [Splitting DebugBlocks] explains the parentage relationship. Test Plan: * ./validate * added a new test Reviewers: bgamari, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14894 Differential Revision: https://phabricator.haskell.org/D4496
* Fix #14916 with an additional validity check in deriveTyDataRyan Scott2018-03-253-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Manually-written instances and standalone-derived instances have the benefit of having the `checkValidInstHead` function run over them, which catches manual instances of built-in types like `(~)` and `Coercible`. However, instances generated from `deriving` clauses weren't being passed through `checkValidInstHead`, leading to confusing results as in #14916. `checkValidInstHead` also has additional validity checks for language extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up until now, GHC has never required these language extensions for `deriving` clause, so to avoid unnecessary breakage, I opted to suppress these language extension checks for `deriving` clauses, just like we currently suppress them for `SPECIALIZE instance` pragmas. Test Plan: make test TEST=T14916 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14916 Differential Revision: https://phabricator.haskell.org/D4501
* testsuite: Add test for #14925Ben Gamari2018-03-252-0/+7
| | | | | | | | | | | | | | Test Plan: Validate Reviewers: alpmestan Reviewed By: alpmestan Subscribers: alpmestan, leftaroundabout, rwbarton, thomie, carter GHC Trac Issues: #14925 Differential Revision: https://phabricator.haskell.org/D4512
* Fix panic on module re-exports of DuplicateRcordFieldsAdam Gundry2018-03-255-0/+42
| | | | | | | | | | | | | | Test Plan: new test overloadedrecflds/should_fail/T14953 Reviewers: mpickering, simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14953 Differential Revision: https://phabricator.haskell.org/D4527
* Fix two pernicious bugs in DeriveAnyClassRyan Scott2018-03-253-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way GHC was handling `DeriveAnyClass` was subtly wrong in two notable ways: * In `inferConstraintsDAC`, we were //always// bumping the `TcLevel` of newly created unification variables, under the assumption that we would always place those unification variables inside an implication constraint. But #14932 showed precisely the scenario where we had `DeriveAnyClass` //without// any of the generated constraints being used inside an implication, which made GHC incorrectly believe the unification variables were untouchable. * Even worse, we were using the generated unification variables from `inferConstraintsDAC` in every single iteration of `simplifyDeriv`. In #14933, however, we have a scenario where we fill in a unification variable with a skolem in one iteration, discard it, proceed on to another iteration, use the same unification variable (still filled in with the old skolem), and try to unify it with a //new// skolem! This results in an utter disaster. The root of both these problems is `inferConstraintsDAC`. This patch fixes the issue by no longer generating unification variables directly in `inferConstraintsDAC`. Instead, we store the original variables from a generic default type signature in `to_metas`, a new field of `ThetaOrigin`, and in each iteration of `simplifyDeriv`, we generate fresh meta tyvars (avoiding the second issue). Moreover, this allows us to more carefully fine-tune the `TcLevel` under which we create these meta tyvars, fixing the first issue. Test Plan: make test TEST="T14932 T14933" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14932, #14933 Differential Revision: https://phabricator.haskell.org/D4507
* testsuite: Add test for #14931Ben Gamari2018-03-254-0/+45
| | | | | | | | | | | | Reviewers: alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14931 Differential Revision: https://phabricator.haskell.org/D4518
* Support adding objects from THAlec Theriault2018-03-254-2/+29
| | | | | | | | | | | | | | | | | | | | | | The user facing TH interface changes are: * 'addForeignFile' is renamed to 'addForeignSource' * 'qAddForeignFile'/'addForeignFile' now expect 'FilePath's * 'RawObject' is now a constructor for 'ForeignSrcLang' * 'qAddTempFile'/'addTempFile' let you request a temporary file from the compiler. Test Plan: unsure about this, added a TH test Reviewers: goldfire, bgamari, angerman Reviewed By: bgamari, angerman Subscribers: hsyl20, mboes, carter, simonmar, bitonic, ljli, rwbarton, thomie GHC Trac Issues: #14298 Differential Revision: https://phabricator.haskell.org/D4217
* Allow PartialTypeSignatures in standalone deriving contextsRyan Scott2018-03-237-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: At its core, this patch is a simple tweak that allows a user to write: ```lang=haskell deriving instance _ => Eq (Foo a) ``` Which is functionally equivalent to: ```lang=haskell data Foo a = ... deriving Eq ``` But with the added flexibility that `StandaloneDeriving` gives you (namely, the ability to use it anywhere, not just in the same module that `Foo` was declared in). This fixes #13324, and should hopefully address a use case brought up in #10607. Currently, only the use of a single, extra-constraints wildcard is permitted in a standalone deriving declaration. Any other wildcard is rejected, so things like `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden. There are quite a few knock-on changes brought on by this change: * The `HsSyn` type used to represent standalone-derived instances was previously `LHsSigType`, which isn't sufficient to hold wildcard types. This needed to be changed to `LHsSigWcType` as a result. * Previously, `DerivContext` was a simple type synonym for `Maybe ThetaType`, under the assumption that you'd only ever be in the `Nothing` case if you were in a `deriving` clause. After this patch, that assumption no longer holds true, as you can also be in this situation with standalone deriving when an extra-constraints wildcard is used. As a result, I changed `DerivContext` to be a proper datatype that reflects the new wrinkle that this patch adds, and plumbed this through the relevant parts of `TcDeriv` and friends. * Relatedly, the error-reporting machinery in `TcErrors` also assumed that if you have any unsolved constraints in a derived instance, then you should be able to fix it by switching over to standalone deriving. This was always sound advice before, but with this new feature, it's possible to have unsolved constraints even when you're standalone-deriving something! To rectify this, I tweaked some constructors of `CtOrigin` a bit to reflect this new subtlety. This requires updating the Haddock submodule. See my fork at https://github.com/RyanGlScott/haddock/commit/067d52fd4be15a1842cbb05f42d9d482de0ad3a7 Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari Reviewed By: simonpj Subscribers: goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #13324 Differential Revision: https://phabricator.haskell.org/D4383
* Special-case record fields ending with hash when deriving ReadRyan Scott2018-03-233-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In commit dbd81f7e86514498218572b9d978373b1699cc5b, a regression was inadvertently introduced which caused derived `Read` instances for record data types with fields ending in a `#` symbol (using `MagicHash`) would no longer parse on valid output. This is ultimately due to the same reasons as #5041, as we cannot parse a field name like `foo#` as a single identifier. We fix this issue by employing the same workaround as in #5041: first parse the identifier name `foo`, then then symbol `#`. This is accomplished by the new `readFieldHash` function in `GHC.Read`. This will likely warrant a `base-4.11.1.0` release. Test Plan: make test TEST=T14918 Reviewers: tdammers, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14918 Differential Revision: https://phabricator.haskell.org/D4502
* Fix over-eager constant folding in bitIntegerSimon Peyton Jones2018-03-222-0/+6
| | | | | | | | | | | The RULE for bitInteger was trying to constant-fold bitInteger 9223372036854775807# which meant constructing a gigantic Integer at compile time. Very bad idea! Easily fixed. Fixes Trac #14959, #14962.
* Allow as-patterns in unidirectional patttern synonymsSimon Peyton Jones2018-03-213-6/+2
| | | | | | | | | | | | | | This patch implements GHC Proposal #94, described here https://github.com/ghc-proposals/ghc-proposals/pull/94 The effect is simply to lift a totally-undocumented restriction to unidirecional pattern synonyms, namely that they can't have as-patterns or n+k patterns. The fix is easy: just remove the checks. I also took the opportunity to improve the manual entry for the semantics of pattern matching for pattern synonyms.
* Fix #14869 by being more mindful of Type vs. ConstraintRyan Scott2018-03-213-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before, we were using `isLiftedTypeKind` in `reifyType` before checking if a type was `Constraint`. But as it turns out, `isLiftedTypeKind` treats `Constraint` the same as `Type`, so every occurrence of `Constraint` would be reified as `Type`! To make things worse, the documentation for `isLiftedTypeKind` stated that it treats `Constraint` //differently// from `Type`, which simply isn't true. This revises the documentation for `isLiftedTypeKind` to reflect reality, and defers the `isLiftedTypeKind` check in `reifyType` so that it does not accidentally swallow `Constraint`. Test Plan: make test TEST=T14869 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14869 Differential Revision: https://phabricator.haskell.org/D4474
* Fix seq# case of exprOkForSpeculationSimon Peyton Jones2018-03-201-1/+1
| | | | | | | | | This subtle patch fixes Trac #5129 (again; comment:20 and following). I took the opportunity to document seq# properly; see Note [seq# magic] in PrelRules, and Note [seq# and expr_ok] in CoreUtils.
* Update T5129 test:Ömer Sinan Ağacan2018-03-201-5/+6
| | | | | | - Add some comments - Remove $s as they complicate desugarer output for no reason - Remove an indirection, case_negative is now main
* Update tests for #12870 to pass with a slow run of the testsuite.Andreas Klebinger2018-03-194-21/+27
| | | | | | | | | | | | | | Test Plan: make slow Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #12870 Differential Revision: https://phabricator.haskell.org/D4486
* Don't permit data types with return kind ConstraintRyan Scott2018-03-197-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, GHC allowed all of the following: ```lang=haskell data Foo1 :: Constraint data family Foo2 :: Constraint data family Foo3 :: k data instance Foo3 :: Constraint ``` Yikes! This is because GHC was confusing `Type` with `Constraint` due to careless use of the `isLiftedTypeKind` function. To respect this distinction, I swapped `isLiftedTypeKind` out for `tcIsStarKind`—which does respect this distinction—in the right places. Test Plan: make test TEST="T14048a T14048b T14048c" Reviewers: bgamari Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, carter GHC Trac Issues: #14048 Differential Revision: https://phabricator.haskell.org/D4479
* Fix #14934 by including axSub0R in typeNatCoAxiomRulesRyan Scott2018-03-194-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | For some reason, `axSub0R` was left out of `typeNatCoAxiomRules` in `TcTypeNats`, which led to disaster when trying to look up `Sub0R` from an interface file, as demonstrated in #14934. The fix is simple—just add `axSub0R` to that list. To help prevent an issue like this happening in the future, I added a `Note [Adding built-in type families]` to `TcTypeNats`, which contains a walkthrough of all the definitions in `TcTypeNats` you need to update when adding a new built-in type family. Test Plan: make test TEST=T14934 Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14934 Differential Revision: https://phabricator.haskell.org/D4508
* Turn a TH Name for built-in syntax into an unqualified RdrNameChaitanya Koparkar2018-03-196-3/+41
| | | | | | | | | | | | | | | | | | | Previously, the Renamer would turn any fully qualified Template Haskell name into a corresponding fully qualified `RdrName`. But this is not what we want for built-in syntax, as it produces unnecessarily qualified names (eg. GHC.Types.[], GHC.Tuple.(,) etc.). Test Plan: ./validate Reviewers: RyanGlScott, bgamari, goldfire Reviewed By: RyanGlScott, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13776 Differential Revision: https://phabricator.haskell.org/D4506
* Improve accuracy of get/setAllocationCounterBen Gamari2018-03-193-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: get/setAllocationCounter didn't take into account allocations in the current block. This was known at the time, but it turns out to be important to have more accuracy when using these in a fine-grained way. Test Plan: New unit test to test incrementally larger allocaitons. Before I got results like this: ``` +0 +0 +0 +0 +0 +4096 +0 +0 +0 +0 +0 +4064 +0 +0 +4088 +4056 +0 +0 +0 +4088 +4096 +4056 +4096 ``` Notice how the results aren't always monotonically increasing. After this patch: ``` +344 +416 +488 +560 +632 +704 +776 +848 +920 +992 +1064 +1136 +1208 +1280 +1352 +1424 +1496 +1568 +1640 +1712 +1784 +1856 +1928 +2000 +2072 +2144 ``` Reviewers: hvr, erikd, simonmar, jrtc27, trommler Reviewed By: simonmar Subscribers: trommler, jrtc27, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4363
* Hoopl: improve postorder calculationMichal Terepeta2018-03-195-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Fix the naming and comments to indicate that we are calculating *reverse* postorder (and not the standard postorder). - Rewrite the calculation to avoid CPS code. I found it fairly difficult to understand and the new one seems faster (according to nofib, decreases compiler allocations by 0.2%) - Remove `LabelsPtr`, which seems unnecessary and could be *really* confusing. For instance, previously: `postorder_dfs_from <block with label X>` and `postorder_dfs_from <label X>` would actually mean quite different things (and give different results). - Change the `Dataflow` module to always use entry of the graph for reverse postorder calculation. This should be the only change in behavior of this commit. Previously, if the caller provided initial facts for some of the labels, we would use those labels for our postorder calculation. However, I don't think that's correct in general - if the initial facts did not contain the entry of the graph, we would never analyze the blocks reachable from the entry but unreachable from the labels provided with the initial facts. It seems that the only analysis that used this was proc-point analysis, which I think would always include the entry block (so I don't think there's any bug due to this). Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com> Test Plan: ./validate Reviewers: bgamari, simonmar Reviewed By: simonmar Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4464
* Improve the warning message of qualified unused imports.HE, Tao2018-03-194-0/+25
| | | | | | | | | | | | | | | | | | | | Pretty-print unused imported names unqualified unconditionally to make the warning message consistent for ambiguous/unambiguous identifiers. Signed-off-by: HE, Tao <sighingnow@gmail.com> Test Plan: make test TEST="T14881" Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14881 Differential Revision: https://phabricator.haskell.org/D4461
* rts: Add --internal-counters RTS flag and several countersDouglas Wilson2018-03-193-7/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing internal counters: * gc_alloc_block_sync * whitehole_spin * gen[g].sync * gen[1].sync are now not shown in the -s report unless --internal-counters is also passed. If --internal-counters is passed we now show the counters above, reformatted, as well as several other counters. In particular, we now count the yieldThread() calls that SpinLocks do as well as their spins. The added counters are: * gc_spin (spin and yield) * mut_spin (spin and yield) * whitehole_threadPaused (spin only) * whitehole_executeMessage (spin only) * whitehole_lockClosure (spin only) * waitForGcThreadsd (spin and yield) As well as the following, which are not SpinLock-like things: * any_work * do_work * scav_find_work See the Note for descriptions of what these counters are. We add busy_wait_nops in these loops along with the counter increment where it was absent. Old internal counters output: ``` gc_alloc_block_sync: 0 whitehole_gc_spin: 0 gen[0].sync: 0 gen[1].sync: 0 ``` New internal counters output: ``` Internal Counters: Spins Yields gc_alloc_block_sync 323 0 gc_spin 9016713 752 mut_spin 57360944 47716 whitehole_gc 0 n/a whitehole_threadPaused 0 n/a whitehole_executeMessage 0 n/a whitehole_lockClosure 0 0 waitForGcThreads 2 415 gen[0].sync 6 0 gen[1].sync 1 0 any_work 2017 no_work 2014 scav_find_work 1004 ``` Test Plan: ./validate Check it builds with #define PROF_SPIN removed from includes/rts/Config.h Reviewers: bgamari, erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #3553, #9221 Differential Revision: https://phabricator.haskell.org/D4302
* Update test for #5129:Ömer Sinan Ağacan2018-03-191-1/+7
| | | | | | | | Make sure it runs with --fast validate with correct optimisation settings (-O1 or above) so that it actually tests the bug. Because the bug is in the simplifier running it with -O0 doesn't test it.
* Slighly improve infix con app pattern errorsÖmer Sinan Ağacan2018-03-143-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given this program: main = do f $ do a <- return 3 c <- do return 5 GHC previously gave this error message: Main.hs:2:7: error: Parse error in pattern: do a <- return 3 c Possibly caused by a missing 'do'? | 2 | f $ do | ^^... What happened is GHC considered the whole `f $ do a <- return 3 c` as a pattern. When parsed as an expression it becomes an infix application of `($)`, and GHC checks left and right hand sides before checking if `($)` is a valid infix constructor name, and shows the first error it got. If instead we first check if the infix op is valid in pattern context, the error message becomes much clearer: Main.hs:2:3: error: Parse error in pattern: f $ do a <- return 3 c Possibly caused by a missing 'do'? | 2 | f $ do | ^^^^^^... This may not entirely fix #11188 but I think it's an improvement. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11188 Differential Revision: https://phabricator.haskell.org/D4497
* Bump Cabal submoduleBen Gamari2018-03-121-2/+0
|
* testsuite: disable T13615 on non-smp targetsSergei Trofimovich2018-03-101-0/+1
| | | | | | | T13615 needs multicore support from RTS: T13615: unknown RTS option: -N15 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* Compacted arrays are pinned for isByteArrayPinned#Simon Marlow2018-03-093-0/+27
| | | | | | | | | | | | Test Plan: New unit test Reviewers: andrewthad, niteria, bgamari, erikd Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14900 Differential Revision: https://phabricator.haskell.org/D4485
* Error message and doc improvements for #14335Ömer Sinan Ağacan2018-03-084-8/+6
| | | | | | | | | | | | | | | | | | | | - Show a more friendly error message when -fplugin is used with -fexternal-interpreter - Add a few words to users guide about the interaction with -fplugin and -fexternal-interpreter - Update test for #14335 Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14335 Differential Revision: https://phabricator.haskell.org/D4456
* Revert "GHCi: Don't remove shadowed bindings from typechecker scope."Ömer Sinan Ağacan2018-03-088-34/+1
| | | | | | | | | | | | | | | | | This reverts commit 59d7ee53906b9cee7f279c1f9567af7b930f8636 and enables the test for #14052. (See #14052 for the discussion) Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14052 Differential Revision: https://phabricator.haskell.org/D4478
* Add -fexternal-dynamic-refsSimon Marlow2018-03-083-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The `-dynamic` flag does two things: * In the code generator, it generates code designed to link against external shared libraries. References outside of the current module go through platform-specific indirection tables (e.g. the GOT on ELF). * It enables a "way", which changes which hi files we look for (`Foo.dyn_hi`) and which libraries we link against. Some specialised applications want the first of these without the second. (I could go into detail here but it's probably not all that important). This diff splits out the code-generation effects of `-dynamic` from the "way" parts of its behaviour, via a new flag `-fexternal-dynamic-refs`. Test Plan: validate Reviewers: niteria, bgamari, erikd Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4477
* Add perf test for #14052Ömer Sinan Ağacan2018-03-074-0/+3512
|
* Fix interpreter with profilingSimon Marlow2018-03-062-5/+3
| | | | | | | | | | | | | | | | | | | This was broken by D3746 and/or D3809, but unfortunately we didn't notice because CI at the time wasn't building the profiling way. Test Plan: ``` cd testsuite/test/profiling/should_run make WAY=ghci-ext-prof ``` Reviewers: bgamari, michalt, hvr, erikd Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14705 Differential Revision: https://phabricator.haskell.org/D4437
* Allow top level ticked string literalsBartosz Nitka2018-03-066-0/+129
| | | | | | | | | | | | | | | | | | | | This reverts f5b275a239d2554c4da0b7621211642bf3b10650 and changes the places that looked for `Lit (MachStr _))` to use `exprIsMbTickedLitString_maybe` to unwrap ticks as necessary. Also updated relevant comments. Test Plan: I added 3 new tests that previously reproduced. GHC HEAD now builds with -g Reviewers: simonpj, simonmar, bgamari, hvr, goldfire Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14779 Differential Revision: https://phabricator.haskell.org/D4470
* Simplify rnLHsInstTypeSimon Peyton Jones2018-03-055-6/+22
| | | | | | | | | | | This patch is preparatory for the main fix for Trac #13324 Here, we simplify rnLHsInstType so that it does not try to figure out the class name. This turns out to have a good (rather than bad) effect on error messages, and it prepares the way for the main event. Plus, less code!
* Fix #14888 by adding more special cases for ArrowTRyan Scott2018-03-053-0/+31
| | | | | | | | | | | | | | | | | | | | | Summary: There were previously some situations where `(->)` would not be desugared or reified as `ArrowT`, leading to various oddities such as those observed in #14888. We now uniformly treat `(->)` as `ArrowT` in Template Haskell–world by checking for any tycon that has the same name as `(->)`, and converting that to `ArrowT`. Test Plan: make test TEST=T14888 Reviewers: goldfire, bgamari, simonpj Reviewed By: goldfire, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14888 Differential Revision: https://phabricator.haskell.org/D4466
* Respect Note [The tcType invariant]Simon Peyton Jones2018-03-052-0/+50
| | | | | | | | | | | | | | | | | | | | | | | I tried to do this with commit 0a12d92a8f65d374f9317af2759af2b46267ad5c Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Wed Dec 13 12:53:26 2017 +0000 Further improvements to well-kinded types The typechecker has the invariant that every type should be well-kinded as it stands, without zonking. See Note [The well-kinded type invariant] in TcType. That invariant was not being upheld, which led to Trac #14174. I fixed part of it, but T14174a showed that there was more. This patch finishes the job. But I didn't get it quite right as Trac #14873 showed. This patch fixes the problem; although I am still a bit unhappy. (See "A worry" in the HsApp case of tc_infer_hs_type.)
* Wombling around in Trac #14808Simon Peyton Jones2018-03-051-0/+6
| | | | | | | | | | | Comment:4 in Trac #14808 explains why I'm unhappy with the current state of affairs -- at least the lack of documentation. This smallpatch does nothing major: * adds comments * uses existing type synonyms more (notably FreeKiTyVarsWithDups) * adds another test case to T14808
* Bump Cabal submodule to 2.2Moritz Angermann2018-03-031-0/+1
| | | | | | | | | | | | | | Requires some ghc-cabal changes as well. Test Plan: ./validate Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: hsyl20, erikd, alpmestan, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4453
* Parenthesize (() :: Constraint) in argument positionRyan Scott2018-03-033-0/+5
| | | | | | | | | | | | | | | | | | | Summary: A simple oversight in the pretty-printer lead to a special case for `() :: Constraint` not being parenthesized correctly when used in an argument position. Easily fixed with a `maybeParen`. Test Plan: make test TEST=T14796 Reviewers: alanz, goldfire, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #14796 Differential Revision: https://phabricator.haskell.org/D4408
* Fix the coverage checker's treatment of existential tyvarsRyan Scott2018-03-023-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | Previously, the pattern-match coverage checker was far too eager to freshen the names of existentially quantified type variables, which led to incorrect sets of type constraints that misled GHC into thinking that certain programs that involve nested GADT pattern matches were non-exhaustive (when in fact they were). Now, we generate extra equality constraints in the ConCon case of the coverage algorithm to ensure that these fresh tyvars align with existing existential tyvars. See `Note [Coverage checking and existential tyvars]` for the full story. Test Plan: make test TEST="T11984 T14098" Reviewers: gkaracha, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #11984, #14098 Differential Revision: https://phabricator.haskell.org/D4434
* Fix #14838 by marking TH-spliced code as FromSourceRyan Scott2018-03-024-0/+48
| | | | | | | | | | | | | | | | | | | | | | Previously, any Template Haskell code that was spliced would be marked as `Generated`, which would completely suppress pattern- match coverage warnings for it, which several folks found confusing. Indeed, Template Haskell-spliced code is "source" code in some sense, as users specifically request that it be put into their program, so changing its designation to `FromSource` makes sense from that perspective. Test Plan: make test TEST=T14838 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14838 Differential Revision: https://phabricator.haskell.org/D4440
* Permit conversion of partially applied PromotedTupleTsRyan Scott2018-03-022-0/+10
| | | | | | | | | | | | | | | | | | Summary: We were simply missing a case in `Convert` for when have a `PromotedTupleT` that wasn't fully saturated. Easily fixed. Test Plan: make test TEST=T14843 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14843 Differential Revision: https://phabricator.haskell.org/D4442
View Lorry Controller Status