summaryrefslogtreecommitdiff
path: root/testsuite
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix #17334 where NCG did not properly update the CFG.wip/andreask/17334Andreas Klebinger2019-10-132-0/+150
| | | | | | | | | | | | | Statements can change the basic block in which instructions are placed during instruction selection. We have to keep track of this switch of the current basic block as we need this information in order to properly update the CFG. This commit implements this change and fixes #17334. We do so by having stmtToInstr return the new block id if a statement changed the basic block.
* Template Haskell: make unary tuples legal (#16881)nineonine2019-10-136-20/+55
|
* Do not add a 'solved dict' for quantified constraintsSimon Peyton Jones2019-10-1211-0/+209
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC has a wonderful-but-delicate mechanism for building recursive dictionaries by adding a goal to the "solved dictionaries" before solving the sub-goals. See Note [Solved dictionaries] in TcSMonad Ticket #17267 showed that if you use this mechanism for local /quantified/ constraints you can get a loop -- or even unsafe coerce. This patch fixes the bug. Specifically * Make TcSMonad.addSolvedDict be conditional on using a /top level/ instance, not a quantified one. * Moreover, we /also/ don't want to add a solved dict for equalities (a~b). * Add lots more comments to Note [Solved dictionaries] to explain the above cryptic stuff. * Extend InstanceWhat to identify those strange built-in equality instances. A couple of other things along the way * Delete the unused Type.isIPPred_maybe. * Stop making addSolvedDict conditional on not being an impolicit parameter. This comes from way back. But it's irrelevant now because IP dicts are never solved via an instance.
* Fix validity checking for inferred typesSimon Peyton Jones2019-10-124-0/+17
| | | | | | | | | | | | | | | | | | | | GHC is suposed to uphold the principle that an /inferred/ type for a let-binding should obey the rules for that module. E.g. we should only accept an inferred higher rank type if we have RankNTypes on. But we were failing to check this: TcValidity.checkValidType allowed arbitrary rank for inferred types. This patch fixes the bug. It might in principle cause some breakage, but if so that's good: the user should add RankNTypes and/or a manual signature. (And almost every package has explicit user signatures for all top-level things anyway.) Let's see. Fixes #17213. Metric Decrease: T10370
* Use newDFunName for both manual and derived instances (#17339)Ryan Scott2019-10-123-0/+42
| | | | | | | | | | | Issue #17339 was caused by using a slightly different version of `newDFunName` for derived instances that, confusingly enough, did not take all arguments to the class into account when generating the `DFun` name. I cannot think of any good reason for doing this, so this patch uses `newDFunName` uniformly for both derived instances and manually written instances alike. Fixes #17339.
* Skip T13767 on DarwinVladislav Zavialov2019-10-121-1/+3
| | | | | | | | | | | | | The CI job fails with: +++ rts/T13676.run/T13676.run.stderr.normalised 2019-10-09 12:27:56.000000000 -0700 @@ -0,0 +1,4 @@ +dyld: Library not loaded: @rpath/libHShaskeline-0.7.5.0-ghc8.9.0.20191009.dylib + Referenced from: /Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib/bin/ghc + Reason: image not found +*** Exception: readCreateProcess: '/Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib/bin/ghc' '-B/Users/builder/builds/ewzE5N2p/0/ghc/ghc/inplace/lib' '-e' ''/''$'/'' == '/''/x0024'/''' +RTS '-tT13676.t' (exit -6): failed Unable to reproduce locally.
* Escape stats file command (#13676)Vladislav Zavialov2019-10-123-0/+49
|
* Much simpler language for PmCheckSebastian Graf2019-10-113-2/+8
| | | | | | | | | | | | | | | | Simon realised that the simple language composed of let bindings, bang patterns and flat constructor patterns is enough to capture the semantics of the source pattern language that are important for pattern-match checking. Well, given that the Oracle is smart enough to connect the dots in this less informationally dense form, which it is now. So we transform `translatePat` to return a list of `PmGrd`s relative to an incoming match variable. `pmCheck` then trivially translates each of the `PmGrd`s into constraints that the oracle understands. Since we pass in the match variable, we incidentally fix #15884 (coverage checks for view patterns) through an interaction with !1746.
* Use addUsedDataCons more judiciously in TcDeriv (#17324)Ryan Scott2019-10-093-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you derive an instance like this: ```hs deriving <...> instance Foo C ``` And the data constructors for `C` aren't in scope, then `doDerivInstErrorChecks1` throws an error. Moreover, it will _only_ throw an error if `<...>` is either `stock` or `newtype`. This is because the code that the `anyclass` or `via` strategies would generate would not require the use of the data constructors for `C`. However, `doDerivInstErrorChecks1` has another purpose. If you write this: ```hs import M (C(MkC1, ..., MkCn)) deriving <...> instance Foo C ``` Then `doDerivInstErrorChecks1` will call `addUsedDataCons` on `MkC1` through `MkCn` to ensure that `-Wunused-imports` does not complain about them. However, `doDerivInstErrorChecks1` was doing this for _every_ deriving strategy, which mean that if `<...>` were `anyclass` or `via`, then the warning about `MkC1` through `MkCn` being unused would be suppressed! The fix is simple enough: only call `addUsedDataCons` when the strategy is `stock` or `newtype`, just like the other code paths in `doDerivInstErrorChecks1`. Fixes #17324.
* PmCheck: Look up parent data family TyCon when populating `PossibleMatches`Sebastian Graf2019-10-082-1/+24
| | | | | | | | | | | | | The vanilla COMPLETE set is attached to the representation TyCon of a data family instance, whereas the user-defined COMPLETE sets are attached to the parent data family TyCon itself. Previously, we weren't trying particularly hard to get back to the representation TyCon to the parent data family TyCon, resulting in bugs like #17207. Now we should do much better. Fixes the original issue in #17207, but I found another related bug that isn't so easy to fix.
* Solve constraints from top-level groups soonerRichard Eisenberg2019-10-0811-82/+75
| | | | | | | | | | | | | | | | | | | | | | | | | Previously, all constraints from all top-level groups (as separated by top-level splices) were lumped together and solved at the end. This could leak metavariables to TH, though, and that's bad. This patch solves each group's constraints before running the next group's splice. Naturally, we now report fewer errors in some cases. One nice benefit is that this also fixes #11680, but in a much simpler way than the original fix for that ticket. Admittedly, the error messages degrade just a bit from the fix from #11680 (previously, we informed users about variables that will be brought into scope below a top-level splice, and now we just report an out-of-scope error), but the amount of complexity required throughout GHC to get that error was just not worth it. This patch thus reverts much of f93c9517a2c6e158e4a5c5bc7a3d3f88cb4ed119. Fixes #16980 Test cases: th/T16980{,a}
* Mark newtype constructors as used in the Coercible solver (#10347)Ryan Scott2019-10-082-5/+8
| | | | | | | | | | | | | Currently, newtype constructors are not marked as used when they are accessed under the hood by uses of `coerce`, as described in #10347. This fixes #10347 by co-opting the `tcg_keep` field of `TcGblEnv` to track uses of newtype constructors in the `Coercible` solver. See `Note [Tracking unused binding and imports]` in `TcRnTypes`. Since #10347 is fixed, I was able to simplify the code in `TcDeriv` slightly, as the hack described in `Note [Newtype deriving and unused constructors]` is no longer necessary.
* PmCheck: Identify some semantically equivalent expressionsSebastian Graf2019-10-081-1/+0
| | | | | | | | | | By introducing a `CoreMap Id` to the term oracle, we can represent syntactically equivalent expressions by the same `Id`. Combine that with `CoreOpt.simpleCoreExpr` and it might even catch non-trivial semantic equalities. Unfortunately due to scoping issues, this will not solve #17208 for view patterns yet.
* Refactor, document, and optimize LLVM configuration loadingBen Gamari2019-10-071-1/+1
| | | | | | | | | | | | As described in the new Note [LLVM Configuration] in SysTools, we now load llvm-targets and llvm-passes lazily to avoid the overhead of doing so when -fllvm isn't used (also known as "the common case"). Noticed in #17003. Metric Decrease: T12234 T12150
* Only flatten up to type family arity in coreFlattenTyFamApp (#16995)Ryan Scott2019-10-072-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Among other uses, `coreFlattenTyFamApp` is used by Core Lint as a part of its check to ensure that each type family axiom reduces according to the way it is defined in the source code. Unfortunately, the logic that `coreFlattenTyFamApp` uses to flatten type family applications disagreed with the logic in `TcFlatten`, which caused it to spuriously complain this program: ```hs type family Param :: Type -> Type type family LookupParam (a :: Type) :: Type where LookupParam (f Char) = Bool LookupParam x = Int foo :: LookupParam (Param ()) foo = 42 ``` This is because `coreFlattenTyFamApp` tries to flatten the `Param ()` in `LookupParam (Param ())` to `alpha` (where `alpha` is a flattening skolem), and GHC is unable to conclude that `alpha` is apart from `f Char`. This patch spruces up `coreFlattenTyFamApp` so that it instead flattens `Param ()` to `alpha ()`, which GHC _can_ know for sure is apart from `f Char`. See `Note [Flatten], wrinkle 3` in `FamInstEnv`.
* New fix for #11647. Avoid side effects like #17171Roland Senn2019-10-047-0/+28
| | | | | If a main module doesn't contain a header, we omit the check whether the main module is exported. With this patch GHC, GHCi and runghc use the same code.
* Add Monad instances to `(,,) a b` and `(,,,) a b c`Fumiaki Kinoshita2019-10-044-3/+5
|
* Add new debug flag -DZTobias Guggenmos2019-10-033-0/+3
| | | | Zeros heap memory after gc freed it.
* testsuite: Mark print037 as fragile, not brokenBen Gamari2019-10-031-2/+2
| | | | See #16205.
* Improve documentation around empty tuples/listsRichard Eisenberg2019-10-032-8/+5
| | | | | | | | | | | | | | This patch also changes the way we handle empty lists, simplifying them somewhat. See Note [Empty lists]. Previously, we had to special-case empty lists in the type-checker. Now no more! Finally, this patch improves some documentation around the ir_inst field used in the type-checker. This breaks a test case, but I really think the problem is #17251, not really related to this patch. Test case: typecheck/should_compile/T13680
* Add `module {-# SOURCE #-} Foo` syntax for hs-boot in bkpJohn Ericson2019-10-033-0/+31
| | | | This is a good convenience for testing.
* Make small INLINE functions behave properlyÖmer Sinan Ağacan2019-10-011-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Simon writes: Currently we check for a type arg rather than isTyCoArg. This in turn makes INLINE things look bigger than they should be, and stops them being inlined into boring contexts when they perfectly well could be. E.g. f x = g <refl> x {-# INLINE g #-} ... (map (f x) xs) ... The context is boring, so don't inline unconditionally. But f's RHS is no bigger than its call, provided you realise that the coercion argument is ultimately cost-free. This happens in practice for $WHRefl. It's not a big deal: at most it means we have an extra function call overhead. But it's untidy, and actually worse than what happens without an INLINE pragma. Fixes #17182 This makes 0.0% change in nofib binary sizes.
* Add testcases inspired by Luke Maranget's pattern match serieswip/add-testcasesSebastian Graf2019-10-015-0/+247
| | | | | | | | | In his paper "Warnings for Pattern Matching", Luke Maranget describes three series in his appendix for which GHC's pattern match checker scaled very badly. We mostly avoid this now with !1752. This commit adds regression tests for each of the series. Fixes #17264.
* Add a bunch of testcases for the pattern match checkerSebastian Graf2019-10-0113-0/+230
| | | | | Adds regression tests for tickets #17207, #17208, #17215, #17216, #17218, #17219, #17248
* testsuite: Mark T3389 as broken in hpc way on i386Ben Gamari2019-09-301-1/+1
| | | | See #17256.
* testsuite: Add minimal test for :doc commandTakenobu Tani2019-09-304-0/+47
| | | | | | | | | | Currently, there are no testcases for GHCi `:doc` command. Perhaps because it was experimental. And it could be changed in the future. But `:doc` command is already useful, so I add a minimal regression test to keep current behavior. See also 85309a3cda for implementation of `:doc` command.
* Move pattern match checker modules to GHC.HsToCore.PmCheckSebastian Graf2019-09-301-1/+1
|
* PmCheck: No ConLike instantiation in pmcheckSebastian Graf2019-09-283-0/+14
| | | | | | | | | | | | | | | | | | | | | | | `pmcheck` used to call `refineToAltCon` which would refine the knowledge we had about a variable by equating it to a `ConLike` application. Since we weren't particularly smart about this in the Check module, we simply freshened the constructors existential and term binders utimately through a call to `mkOneConFull`. But that instantiation is unnecessary for when we match against a concrete pattern! The pattern will already have fresh binders and field types. So we don't call `refineToAltCon` from `Check` anymore. Subsequently, we can simplify a couple of call sites and functions in `PmOracle`. Also implementing `computeCovered` becomes viable and we don't have to live with the hack that was `addVarPatVecCt` anymore. A side-effect of not indirectly calling `mkOneConFull` anymore is that we don't generate the proper strict argument field constraints anymore. Instead we now desugar ConPatOuts as if they had bangs on their strict fields. This implies that `PmVar` now carries a `HsImplBang` that we need to respect by a (somewhat ephemeral) non-void check. We fix #17234 in doing so.
* testsuite: Mark TH tests as fragile in LLVM built external-interpreterBen Gamari2019-09-271-9/+4
| | | | | Due to #16087. This drops the previous explicit list of broken tests and rather encompasses the entire set of tests since they all appear to be broken.
* testsuite: Mark T3389 as broken in profiled ways on i386Ben Gamari2019-09-271-1/+2
| | | | As noted in #17256.
* testsuite: Mark hs_try_putmvar003 as fragile in threaded1Ben Gamari2019-09-271-1/+2
| | | | | Due to #16361. Note that I'm leaving out threaded2 since it's not clear whether the single crash in that way was due to other causes.
* testsuite: Mark cgrun071 as broken on i386Ben Gamari2019-09-271-1/+4
| | | | As described in #17247.
* Add test for expected dependencies of 'Parser'Shayne Fletcher2019-09-272-0/+65
|
* PmCheck: Look at precendence to give type signatures to some wildcardsSebastian Graf2019-09-2717-49/+50
| | | | | | | | | Basically do what we currently only do for -XEmptyCase in other cases where adding the type signature won't distract from pattern matches in other positions. We use the precedence to guide us, equating "need to parenthesise" with "too much noise".
* Make -fbyte-code prevent unboxed tuples/sums from implying object code (#16876)Ryan Scott2019-09-265-0/+32
| | | | | | | | | | | | | | | | | | | | This resolves #16876 by making the explicit use of `-fbyte-code` prevent code that enables `UnboxedTuples` or `UnboxedSums` from automatically compiling to object code. This allows for a nice middle ground where most code that enables `UnboxedTuples`/-`Sums` will still benefit from automatically enabling `-fobject-code`, but allows power users who wish to avoid this behavior in certain corner cases (such as `lens`, whose use case is documented in #16876) to do so. Along the way, I did a little cleanup of the relevant code and documentation: * `enableCodeGenForUnboxedTuples` was only checking for the presence of `UnboxedTuples`, but `UnboxedSums` has the same complications. I fixed this and renamed the function to `enableCodeGenForUnboxedTuplesOrSums`. * I amended the users' guide with a discussion of these issues.
* Standalone kind signatures (#16794)wip/top-level-kind-signaturesVladislav Zavialov2019-09-25208-200/+1571
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst With this patch, a type constructor can now be given an explicit standalone kind signature: {-# LANGUAGE StandaloneKindSignatures #-} type Functor :: (Type -> Type) -> Constraint class Functor f where fmap :: (a -> b) -> f a -> f b This is a replacement for CUSKs (complete user-specified kind signatures), which are now scheduled for deprecation. User-facing changes ------------------- * A new extension flag has been added, -XStandaloneKindSignatures, which implies -XNoCUSKs. * There is a new syntactic construct, a standalone kind signature: type <name> :: <kind> Declarations of data types, classes, data families, type families, and type synonyms may be accompanied by a standalone kind signature. * A standalone kind signature enables polymorphic recursion in types, just like a function type signature enables polymorphic recursion in terms. This obviates the need for CUSKs. * TemplateHaskell AST has been extended with 'KiSigD' to represent standalone kind signatures. * GHCi :info command now prints the kind signature of type constructors: ghci> :info Functor type Functor :: (Type -> Type) -> Constraint ... Limitations ----------- * 'forall'-bound type variables of a standalone kind signature do not scope over the declaration body, even if the -XScopedTypeVariables is enabled. See #16635 and #16734. * Wildcards are not allowed in standalone kind signatures, as partial signatures do not allow for polymorphic recursion. * Associated types may not be given an explicit standalone kind signature. Instead, they are assumed to have a CUSK if the parent class has a standalone kind signature and regardless of the -XCUSKs flag. * Standalone kind signatures do not support multiple names at the moment: type T1, T2 :: Type -> Type -- rejected type T1 = Maybe type T2 = Either String See #16754. * Creative use of equality constraints in standalone kind signatures may lead to GHC panics: type C :: forall (a :: Type) -> a ~ Int => Constraint class C a where f :: C a => a -> Int See #16758. Implementation notes -------------------- * The heart of this patch is the 'kcDeclHeader' function, which is used to kind-check a declaration header against its standalone kind signature. It does so in two rounds: 1. check user-written binders 2. instantiate invisible binders a la 'checkExpectedKind' * 'kcTyClGroup' now partitions declarations into declarations with a standalone kind signature or a CUSK (kinded_decls) and declarations without either (kindless_decls): * 'kinded_decls' are kind-checked with 'checkInitialKinds' * 'kindless_decls' are kind-checked with 'getInitialKinds' * DerivInfo has been extended with a new field: di_scoped_tvs :: ![(Name,TyVar)] These variables must be added to the context in case the deriving clause references tcTyConScopedTyVars. See #16731.
* base: Move Ix typeclass to GHC.IxBen Gamari2019-09-252-18/+18
| | | | | The `Ix` class seems rather orthogonal to its original home in `GHC.Arr`.
* PmCheck: Only ever check constantly many models against a single patternSebastian Graf2019-09-255-3/+65
| | | | | | | | | | | | | | | | | | | | | | | | | Introduces a new flag `-fmax-pmcheck-deltas` to achieve that. Deprecates the old `-fmax-pmcheck-iter` mechanism in favor of this new flag. From the user's guide: Pattern match checking can be exponential in some cases. This limit makes sure we scale polynomially in the number of patterns, by forgetting refined information gained from a partially successful match. For example, when matching `x` against `Just 4`, we split each incoming matching model into two sub-models: One where `x` is not `Nothing` and one where `x` is `Just y` but `y` is not `4`. When the number of incoming models exceeds the limit, we continue checking the next clause with the original, unrefined model. This also retires the incredibly hard to understand "maximum number of refinements" mechanism, because the current mechanism is more general and should catch the same exponential cases like PrelRules at the same time. ------------------------- Metric Decrease: T11822 -------------------------
* Add -Wderiving-defaults (#15839)Kari Pahula2019-09-255-3/+26
| | | | | | Enabling both DeriveAnyClass and GeneralizedNewtypeDeriving can cause a warning when no explicit deriving strategy is in use. This change adds an enable/suppress flag for it.
* testsuite: Mark threadstatus-9333 as fragile in profthreadedBen Gamari2019-09-241-1/+1
| | | | Due to #16555.
* Add -fkeep-going to make compiler continue despite errors (#15424)Kari Pahula2019-09-2311-0/+50
| | | | | Add a new optional failure handling for upsweep which continues the compilation on other modules if any of them has errors.
* Get rid of PmFakewip/pmcheck-nofakeSebastian Graf2019-09-211-1/+1
| | | | | | | | | | | | | | | | | | | The pattern match oracle can now cope with the abundance of information that ViewPatterns, NPlusKPats, overloaded lists, etc. provide. No need to have PmFake anymore! Also got rid of a spurious call to `allCompleteMatches`, which we used to call *for every constructor* match. Naturally this blows up quadratically for programs like `ManyAlternatives`. ------------------------- Metric Decrease: ManyAlternatives Metric Increase: T11822 -------------------------
* Fix bogus type of case expressionwip/T17056Simon Peyton Jones2019-09-203-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue #17056 revealed that we were sometimes building a case expression whose type field (in the Case constructor) was bogus. Consider a phantom type synonym type S a = Int and we want to form the case expression case x of K (a::*) -> (e :: S a) We must not make the type field of the Case constructor be (S a) because 'a' isn't in scope. We must instead expand the synonym. Changes in this patch: * Expand synonyms in the new function CoreUtils.mkSingleAltCase. * Use mkSingleAltCase in MkCore.wrapFloat, which was the proximate source of the bug (when called by exprIsConApp_maybe) * Use mkSingleAltCase elsewhere * Documentation CoreSyn new invariant (6) in Note [Case expression invariants] CoreSyn Note [Why does Case have a 'Type' field?] CoreUtils Note [Care with the type of a case expression] * I improved Core Lint's error reporting, which was pretty confusing in this case, because it didn't mention that the offending type was the return type of a case expression. * A little bit of cosmetic refactoring in CoreUtils
* testsuite: Add test for #17202Ben Gamari2019-09-202-0/+21
|
* Module hierarchy: Hs (#13009)Sylvain Henry2019-09-2016-40/+40
| | | | | | | Add GHC.Hs module hierarchy replacing hsSyn. Metric Increase: haddock.compiler
* testsuite: Add testcase for #17206Ben Gamari2019-09-193-0/+19
|
* Add a regression test for #11822Sebastian Graf2019-09-193-4/+54
| | | | | The particular test is already fixed, but the issue seems to have multiple different test cases lumped together.
* Test #17077.Richard Eisenberg2019-09-193-0/+14
|
* Use level numbers for generalisationRichard Eisenberg2019-09-192-6/+12
| | | | | | | | This fixes #15809, and is covered in Note [Use level numbers for quantification] in TcMType. This patch removes the "global tyvars" from the environment, a nice little win.
* Refactor kindGeneralize and friendsRichard Eisenberg2019-09-191-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit should have no change in behavior.(*) The observation was that Note [Recipe for checking a signature] says that every metavariable in a type-checked type must either (A) be generalized (B) be promoted (C) be zapped. Yet the code paths for doing these were all somewhat separate. This led to some steps being skipped. This commit shores this all up. The key innovation is TcHsType.kindGeneralizeSome, with appropriate commentary. This commit also sets the stage for #15809, by turning the WARNing about bad level-numbers in generalisation into an ASSERTion. The actual fix for #15809 will be in a separate commit. Other changes: * zonkPromoteType is now replaced by kindGeneralizeNone. This might have a small performance degradation, because zonkPromoteType zonked and promoted all at once. The new code path promotes first, and then zonks. * A call to kindGeneralizeNone was added in tcHsPartialSigType. I think this was a lurking bug, because it did not follow Note [Recipe for checking a signature]. I did not try to come up with an example showing the bug. This is the (*) above. Because of this change, there is an error message regression in partial-sigs/should_fail/T14040a. This problem isn't really a direct result of this refactoring, but is a symptom of something deeper. See #16775, which addresses the deeper problem. * I added a short-cut to quantifyTyVars, in case there's nothing to quantify. * There was a horribly-outdated Note that wasn't referred to. Gone now. * While poking around with T14040a, I discovered a small mistake in the Coercion.simplifyArgsWorker. Easy to fix, happily. * See new Note [Free vars in coercion hole] in TcMType. Previously, we were doing the wrong thing when looking at a coercion hole in the gather-candidates algorithm. Fixed now, with lengthy explanation. Metric Decrease: T14683
View Lorry Controller Status