summaryrefslogtreecommitdiff
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
...
* Rename SigTv to TyVarTv (#15480)Joachim Breitner2018-08-1615-164/+156
| | | | | | | | | | | | | because since #15050, these are no longer used in pattern SIGnatures, but still in other places where meta-variables should only be unified with TYpe VARiables. I also found mentions of `SigTv` in parts of the renamer and desugarer that do not seem to directly relate to `SigTv` as used in the type checker, but rather to uses of `forall a.` in type signatures. I renamed these to `ScopedTv`. Differential Revision: https://phabricator.haskell.org/D5074
* Fix #15527 by pretty-printing an RdrName prefixlyRyan Scott2018-08-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary: When `(.) @Int` is used without enabling `TypeApplications`, the resulting error message will pretty-print the (symbolic) `RdrName` `(.)`. However, it does so without parenthesizing it, which causes the pretty-printed expression to appear as `.@Int`. Yuck. Since the expression in a type application will always be prefix, we can fix this issue by using `pprPrefixOcc` instead of plain ol' `ppr`. Test Plan: make test TEST=T15527 Reviewers: bgamari, monoidal, simonpj Reviewed By: monoidal, simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15527 Differential Revision: https://phabricator.haskell.org/D5071
* primops: Drop documentation for WORD_SIZE_IN_BITS < 32Chai T. Rex2018-08-161-4/+5
| | | | Removes documentation suggesting that 30 and 31-bit code generation is supported (in support of https://github.com/ghc/ghc/commit/290889927244c79479c4347dfa6c851a134dd6e0).
* Cosmetics in GraphColorKrzysztof Gogolewski2018-08-151-1/+1
| | | | | This allows to run ghc-in-ghci when :set -XTypeApplications is in .ghciconfig.
* primops: Drop support for WORD_SIZE_IN_BITS < 32Ben Gamari2018-08-151-27/+0
| | | | | | | | | | | | | | | | Summary: Fixes #15486. Test Plan: Validate Reviewers: monoidal Reviewed By: monoidal Subscribers: rwbarton, carter GHC Trac Issues: #15486 Differential Revision: https://phabricator.haskell.org/D5050
* Properly designate LambdaCase alts as CaseAlt in THRyan Scott2018-08-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: When `\case` expressions are parsed normally, their alternatives are marked as `CaseAlt` (which means that they are pretty-printed without a `\` character in front of them, unlike for lambda expressions). However, `\case` expressions created by way of Template Haskell (in `Convert`) inconsistently designated the case alternatives as `LambdaExpr`, causing them to be pretty-printed poorly (as shown in #15518). The fix is simple: use `CaseAlt` consistently. Test Plan: make test TEST=T15518 Reviewers: goldfire, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15518 Differential Revision: https://phabricator.haskell.org/D5069
* Suppress redundant givens during error reportingRyan Scott2018-08-121-2/+42
| | | | | | | | | | | | | | | | | | | Summary: When GHC reports that it cannot solve a constraint in error messages, it often reports what given constraints it has in scope. Unfortunately, sometimes redundant constraints (like `* ~ *`, from #15361) can sneak in. The fix is simple: blast away these redundant constraints using `mkMinimalBySCs`. Test Plan: make test TEST=T15361 Reviewers: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15361 Differential Revision: https://phabricator.haskell.org/D5002
* Check if files are same in combineSrcSpansZubin Duggal2018-08-121-2/+4
| | | | | | | | | | | | | | | | Summary: If this is not checked, SrcSpans are sometimes mangled by CPP. Test Plan: ./validate Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: dfeuer, rwbarton, thomie, carter GHC Trac Issues: #15279 Differential Revision: https://phabricator.haskell.org/D4866
* --show-iface: Qualify all non-local namesSimon Jakobi2018-08-122-7/+19
| | | | | | | | | | | | | | | | | | | | Summary: In order to disambiguate names from different modules, qualify all names that don't originate in the current module. Also update docs for QueryQualifyName Test Plan: validate Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter, tdammers GHC Trac Issues: #15269 Differential Revision: https://phabricator.haskell.org/D4852
* Filter plugin dylib locationsChristiaan Baaij2018-08-111-7/+28
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously we just created a cartesian product of the library paths of the plugin package and the libraries of the package. Of course, some of these combinations result in a filepath of a file doesn't exists, leading to #15475. Instead of making `haskFile` return Nothing in case a file doesn't exist (which would hide errors), we look at all the possible dylib locations and ensure that at least one of those locations is an existing file. If the list turns out to be empty however, we panic. Reviewers: mpickering, bgamari Reviewed By: mpickering Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15475 Differential Revision: https://phabricator.haskell.org/D5048
* Turn on MonadFail desugaring by defaultHerbert Valerio Riedel2018-08-0714-50/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This contains two commits: ---- Make GHC's code-base compatible w/ `MonadFail` There were a couple of use-sites which implicitly used pattern-matches in `do`-notation even though the underlying `Monad` didn't explicitly support `fail` This refactoring turns those use-sites into explicit case discrimations and adds an `MonadFail` instance for `UniqSM` (`UniqSM` was the worst offender so this has been postponed for a follow-up refactoring) --- Turn on MonadFail desugaring by default This finally implements the phase scheduled for GHC 8.6 according to https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Transitionalstrategy This also preserves some tests that assumed MonadFail desugaring to be active; all ghc boot libs were already made compatible with this `MonadFail` long ago, so no changes were needed there. Test Plan: Locally performed ./validate --fast Reviewers: bgamari, simonmar, jrtc27, RyanGlScott Reviewed By: bgamari Subscribers: bgamari, RyanGlScott, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D5028
* Bump binary submodule to 0.8.6.0Ben Gamari2018-08-071-1/+1
| | | | | This is actually a decrease in the version number since a bump to 0.10 wasn't actually necessary.
* Support typechecking of type literals in backpackPiyush P Kurur2018-08-062-1/+17
| | | | | | | | | | | | | | | | | Backpack is unable to type check signatures that expect a data which is a type level literal. This was reported in issue #15138. These commits are a fix for this. It also includes a minimal test case that was mentioned in the issue. Reviewers: bgamari, ezyang, goldfire Reviewed By: bgamari, ezyang Subscribers: simonpj, ezyang, rwbarton, thomie, carter GHC Trac Issues: #15138 Differential Revision: https://phabricator.haskell.org/D4951
* Improve error message for flags with missing required arguments (#12625)roland2018-08-061-2/+4
| | | | | | | | | | | | | | Test Plan: make TEST=T12625 Reviewers: jstolarek, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #12625 Differential Revision: https://phabricator.haskell.org/D5030
* Stop the linker panicMoritz Angermann2018-08-062-25/+47
| | | | | | | | | | | | | | | | | | | | | | | If we fail to initialize the liker properly, we still set the `initLinkerDone`. In fact we even set that prior to actually initializing the linker. However if the linker initialization fails, we the `Done` state is still true. As such we run into the `Dynamic Linker not initialised` error. Which while technically corret is confusing as it pulls the attation away from the real issue. This change puts the Done state into an MVar, and as such ensureing that all parallel access needs to wait for the linker to be actually initialized, or try to re-initilize if it fails. Reviewers: bgamari, RyanGlScott, simonmar, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #9868, #10355, #13137, #13607, #13531 Differential Revision: https://phabricator.haskell.org/D5012
* Allow scoped type variables refer to typesJoachim Breitner2018-08-052-40/+53
| | | | | | | | | | | | This patch implements GHC proposal 29: (sorry, URL is too long for the commit message linter) and fixess #15050. The change is simple: Just use a different meta variable form. Test suite and documentation updated. Differential Revision: https://phabricator.haskell.org/D4980
* Fix typosKrzysztof Gogolewski2018-08-054-6/+6
|
* Refactor printMinimalImports (#15439)vrom9112018-08-051-21/+27
| | | | | | | | | | | | | | | | Summary: Split into getMinimalImports and printMinimalImports. Export both functions from RnNames module. Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15439 Differential Revision: https://phabricator.haskell.org/D5045
* Bump binary submoduleBen Gamari2018-08-031-1/+1
|
* Remove decideKindGeneralisationPlanRichard Eisenberg2018-08-0216-226/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TypeInType came with a new function: decideKindGeneralisationPlan. This type-level counterpart to the term-level decideGeneralisationPlan chose whether or not a kind should be generalized. The thinking was that if `let` should not be generalized, then kinds shouldn't either (under the same circumstances around -XMonoLocalBinds). However, this is too conservative -- the situation described in the motivation for "let should be be generalized" does not occur in types. This commit thus removes decideKindGeneralisationPlan, always generalizing. One consequence is that tc_hs_sig_type_and_gen no longer calls solveEqualities, which reports all unsolved constraints, instead relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect of this is that reporing kind errors gets delayed more frequently. This seems to be a net benefit in error reporting; often, alongside a kind error, the type error is now reported (and users might find type errors easier to understand). Some of these errors ended up at the top level, where it was discovered that the GlobalRdrEnv containing the definitions in the local module was not in the TcGblEnv, and thus errors were reported with qualified names unnecessarily. This commit rejiggers some of the logic around captureTopConstraints accordingly. One error message (typecheck/should_fail/T1633) is a regression, mentioning the name of a default method. However, that problem is already reported as #10087, its solution is far from clear, and so I'm not addressing it here. This commit fixes #15141. As it's an internal refactor, there is no concrete test case for it. Along the way, we no longer need the hsib_closed field of HsImplicitBndrs (it was used only in decideKindGeneralisationPlan) and so it's been removed, simplifying the datatype structure. Along the way, I removed code in the validity checker that looks at coercions. This isn't related to this patch, really (though it was, at one point), but it's an improvement, so I kept it. This updates the haddock submodule.
* Remove obsolete fileHerbert Valerio Riedel2018-08-021-4/+0
| | | | | | This was missed by 0960a37868e6d08857e86465c8ca346b29b1c813 [skip ci]
* Fix #15415 and simplify tcWildCardBindersVladislav Zavialov2018-08-012-27/+14
| | | | | | | | | | | | | | Test Plan: Validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: RyanGlScott, rwbarton, thomie, carter GHC Trac Issues: #15415 Differential Revision: https://phabricator.haskell.org/D5022
* Fix #15450 by refactoring checkEmptyCase'Ryan Scott2018-08-011-40/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `checkEmptyCase'` (the code path for coverage-checking `EmptyCase` expressions) had a fair bit of code duplication from the code path for coverage-checking non-`EmptyCase` expressions, and to make things worse, it behaved subtly different in some respects (for instance, emitting different warnings under unsatisfiable constraints, as shown in #15450). This patch attempts to clean up both this discrepancy and the code duplication by doing the following: * Factor out a `pmInitialTmTyCs` function, which returns the initial set of term and type constraints to use when beginning coverage checking. If either set of constraints is unsatisfiable, we use an empty set in its place so that we can continue to emit as many warnings as possible. (The code path for non-`EmptyCase` expressions was doing this already, but not the code path for `EmptyCase` expressions, which is the root cause of #15450.) Along the way, I added a `Note` to explain why we do this. * Factor out a `pmIsSatisfiable` constraint which checks if a set of term and type constraints are satisfiable. This does not change any existing behavior; this is just for the sake of deduplicating code. Test Plan: make test TEST=T15450 Reviewers: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15450 Differential Revision: https://phabricator.haskell.org/D5017
* linker: Nub rpathsMoritz Angermann2018-08-011-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When compiling and linking files in `ghci`, we keep adding rpath arguments to the linker command invoation. If those are identical we should `nub` them out. Otherwise we not only risk overflowing the argument limit, but also embed huge amounts of identical rpath values into the dynamic library, eventually leading to the overflow of the load command size limit, due to the number of rpath entries alone. A further improvement could be to pass `-Xlinker -dead_strip_dylibs`; that however might be stipping too aggressively, and potentially lead to missing symbols? For the time being I suggest to only do the nubbing and if need be to provide -Wl,-dead_strip_dylibs when invoking ghci. Test Plan: ./validate Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15446 Differential Revision: https://phabricator.haskell.org/D5021
* Plugin dependency information is stored separatelyChristiaan Baaij2018-08-016-19/+124
| | | | | | | | | | | | | | | | | | | | | | | | We need to store the used plugins so that we recompile a module when a plugin that it uses is recompiled. However, storing the `ModuleName`s of the plugins used by a module in the `dep_mods` field made the rest of GHC think that they belong in the HPT, causing at least the issues reported in #15234 We therefor store the `ModuleName`s of the plugins in a new field, `dep_plgins`, which is only used the the recompilation logic. Reviewers: mpickering, bgamari Reviewed By: mpickering, bgamari Subscribers: alpmestan, rwbarton, thomie, carter GHC Trac Issues: #15234 Differential Revision: https://phabricator.haskell.org/D4937
* Remove the type-checking knot.Richard Eisenberg2018-08-0112-225/+194
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug #15380 hangs because a knot-tied TyCon ended up in a kind. Looking at the code in tcInferApps, I'm amazed this hasn't happened before! I couldn't think of a good way to fix it (with dependent types, we can't really keep types out of kinds, after all), so I just went ahead and removed the knot. This was remarkably easy to do. In tcTyVar, when we find a TcTyCon, just use it. (Previously, we looked up the knot-tied TyCon and used that.) Then, during the final zonk, replace TcTyCons with the real, full-blooded TyCons in the global environment. It's all very easy. The new bit is explained in the existing Note [Type checking recursive type and class declarations] in TcTyClsDecls. Naturally, I removed various references to the knot and the zonkTcTypeInKnot (and related) functions. Now, we can print types during type checking with abandon! NB: There is a teensy error message regression with this patch, around the ordering of quantified type variables. This ordering problem is fixed (I believe) with the patch for #14880. The ordering affects only internal variables that cannot be instantiated with any kind of visible type application. There is also a teensy regression around the printing of types in TH splices. I think this is really a TH bug and will file separately. Test case: dependent/should_fail/T15380
* Revert "Don't inline functions with RULES too early"Ben Gamari2018-08-014-55/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit causes significant performance regressions: ``` bytes allocated value is too high: Expected T9872d(normal) bytes allocated: 578498120 +/-5% Lower bound T9872d(normal) bytes allocated: 549573214 Upper bound T9872d(normal) bytes allocated: 607423026 Actual T9872d(normal) bytes allocated: 677179968 Deviation T9872d(normal) bytes allocated: 17.1 % bytes allocated value is too high: Expected T9872c(normal) bytes allocated: 3096670112 +/-5% Lower bound T9872c(normal) bytes allocated: 2941836606 Upper bound T9872c(normal) bytes allocated: 3251503618 Actual T9872c(normal) bytes allocated: 3601872536 Deviation T9872c(normal) bytes allocated: 16.3 % bytes allocated value is too high: Expected T9872b(normal) bytes allocated: 3730686224 +/-5% Lower bound T9872b(normal) bytes allocated: 3544151912 Upper bound T9872b(normal) bytes allocated: 3917220536 Actual T9872b(normal) bytes allocated: 4374298272 Deviation T9872b(normal) bytes allocated: 17.3 % bytes allocated value is too high: Expected T9872a(normal) bytes allocated: 2729927408 +/-5% Lower bound T9872a(normal) bytes allocated: 2593431037 Upper bound T9872a(normal) bytes allocated: 2866423779 Actual T9872a(normal) bytes allocated: 3225788896 Deviation T9872a(normal) bytes allocated: 18.2 % ``` It's not clear that this was intentional so I'm going to revert for now. This reverts commit 2110738b280543698407924a16ac92b6d804dc36.
* Don't inline functions with RULES too earlySimon Peyton Jones2018-07-314-10/+55
| | | | | | | | | Trac #15445 showed that a function with an automatically generated specialisation RULE coudl be inlined before the RULE had a chance to fire. This patch attaches a NOINLINE[2] activation to the Id, to stop this happening.
* Fix #15385 by using addDictsDs in matchGuardsRyan Scott2018-07-305-40/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When coverage checking pattern-matches, we rely on the call sites in the desugarer to populate the local dictionaries and term evidence in scope using `addDictsDs` and `addTmCsDs`. But it turns out that only the call site for desugaring `case` expressions was actually doing this properly. In another part of the desugarer, `matchGuards` (which handles pattern guards), it did not update the local dictionaries in scope at all, leading to #15385. Fixing this is relatively straightforward: just augment the `BindStmt` case of `matchGuards` to use `addDictsDs` and `addTmCsDs`. Accomplishing this took a little bit of import/export tweaking: * We now need to export `collectEvVarsPat` from `HsPat.hs`. * To avoid an import cycle with `Check.hs`, I moved `isTrueLHsExpr` from `DsGRHSs.hs` to `DsUtils.hs`, which resides lower on the import chain. Test Plan: make test TEST=T15385 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15385 Differential Revision: https://phabricator.haskell.org/D4968
* Fix #15453: bug in ForAllCo case in opt_trans_ruleNingning Xie2018-07-291-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Given ``` co1 = \/ tv1 : eta1. r1 co2 = \/ tv2 : eta2. r2 ``` We would like to optimize `co1; co2` so we push transitivity inside forall. It should be ``` \/tv1 : (eta1;eta2). (r1; r2[tv2 |-> tv1 |> eta1]) ``` It is implemented in the ForAllCo case in opt_trans_rule in OptCoercion. However current implementation is not right: ``` r2' = substCoWithUnchecked [tv2] [TyVarTy tv1] r2 -- ill-kinded! ``` This patch corrects it to be ``` r2' = substCoWithUnchecked [tv2] [mkCastTy (TyVarTy tv1) eta1] r2 ``` Test Plan: validate Reviewers: bgamari, goldfire, RyanGlScott Reviewed By: RyanGlScott Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15453 Differential Revision: https://phabricator.haskell.org/D5018
* Fix Ar crashing on odd-sized object files (Trac #15396)Krzysztof Gogolewski2018-07-271-2/+11
| | | | | | | | | | | | | | | | Summary: All the work was done by Moritz Angermann. Test Plan: validate Reviewers: angerman, RyanGlScott, bgamari Reviewed By: angerman Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15396 Differential Revision: https://phabricator.haskell.org/D5013
* Fix endian issues in ghc-heapPeter Trommler2018-07-271-3/+6
| | | | | | | | | | | | | | | | | | | | | | In test heap_all arity and n_args were swapped on big endian systems. Take care of endianness when reading parts of a machine word from a `Word`. This fixes one out of 36 failing tests reported in #15399. Test Plan: validate Reviewers: simonmar, bgamari, hvr, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15399 Differential Revision: https://phabricator.haskell.org/D5001
* Modifications to support loading GHC into GHCiMichael Sloan2018-07-271-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change was previously part of [D4904](https://phabricator.haskell.org/D4904), but is being split off to aid in getting this reviewed and merged. * The compiler code is built with `NoImplicitPrelude`, but GHCi's modules are incompatible with it. So, this adds the pragma to all GHCi modules that didn't have it, and adds imports of Prelude. * In order to run GHC within itself, a `call of 'initGCStatistics` needed to be skipped. This uses CPP to skip it when `-DGHC_LOADED_INTO_GHCI` is set. * There is an environment variable workaround suggested by Ben Gamari [1], where `_GHC_TOP_DIR` can be used to specify GHC's top dir if `-B` isn't provided. This can be used to solve a problem where the GHC being run within GHCi attempts to look in `inplace/lib/lib/` instead of `inplace/lib/`. [1]: https://phabricator.haskell.org/D4904#135438 Reviewers: goldfire, bgamari, erikd, alpmestan Reviewed By: alpmestan Subscribers: alpmestan, lelf, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4986
* Run StgCse after unarise, fixes #15300Ömer Sinan Ağacan2018-07-274-32/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Given two unboxed sum terms: (# 1 | #) :: (# Int | Int# #) (# 1 | #) :: (# Int | Int #) These two terms are not equal as they unarise to different unboxed tuples. However StgCse was thinking that these are equal, and replacing one of these with a binder to the other. To not deal with unboxed sums in StgCse we now do it after unarise. For StgCse to maintain post-unarise invariants we factor-out case binder in-scopeness check to `stgCaseBndrInScope` and use it in StgCse. Also did some refactoring in SimplStg. Another way to fix this would be adding a special case in StgCse to not bring unboxed sum binders in scope: diff --git a/compiler/simplStg/StgCse.hs b/compiler/simplStg/StgCse.hs index 6c740ca4cb..93a0f8f6ad 100644 --- a/compiler/simplStg/StgCse.hs +++ b/compiler/simplStg/StgCse.hs @@ -332,7 +332,11 @@ stgCseExpr env (StgLetNoEscape binds body) stgCseAlt :: CseEnv -> OutId -> InStgAlt -> OutStgAlt stgCseAlt env case_bndr (DataAlt dataCon, args, rhs) = let (env1, args') = substBndrs env args - env2 = addDataCon case_bndr dataCon (map StgVarArg args') env1 + env2 + | isUnboxedSumCon dataCon + = env1 + | otherwise + = addDataCon case_bndr dataCon (map StgVarArg args') env1 -- see note [Case 2: CSEing case binders] rhs' = stgCseExpr env2 rhs in (DataAlt dataCon, args', rhs') I think this patch seems better in that it doesn't add a special case to StgCse. Test Plan: Validate. I tried to come up with a minimal example but failed. I thought a simple program like data T = T (# Int | Int #) (# Int# | Int #) case T (# 1 | #) (# 1 | #) of ... should be enough to trigger this bug, but for some reason StgCse doesn't do anything on this program. Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15300 Differential Revision: https://phabricator.haskell.org/D4962
* Fail instead of panic-ing when qAddTopDecls has conversion errorMichael Sloan2018-07-271-1/+3
| | | | | | | | | | | | | | | | | | See https://ghc.haskell.org/trac/ghc/ticket/14627 for an example where GHC panics when using qAddTopDecls on [d| f = Bool |]. Instead, it should be a normal error message, and that's what this change is for. It does not entirely resolve Trac#14627, since "Illegal variable name: 'bool'" isn't a very good error for this cirumstance. Test Plan: Manually tested. Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4914
* Small refactor in desugar of pattern matchingSimon Peyton Jones2018-07-275-20/+54
| | | | | | | | | | | | | | | | In reviewing Phab:D4968 for Trac #15385 I saw a small but simple refactor to avoid unnecessary work in the desugarer. This patch just arranges to call matchSinglePatVar v ... rather than matchSinglePat (Var v) ... The more specialised function already existed, as match_single_pat_var I also added more comments about decideBangHood
* Refactor (~) to reduce the suerpclass stackSimon Peyton Jones2018-07-2710-77/+111
| | | | | | | | | | | | | | | | | | | | | | | The constraint (~) used to be (effectively): class a ~~ b => (a :: k) ~ (b :: k) but, with this patch, it is now defined uniformly with (~~) and Coercible like this: class a ~# b => (a :: k) ~ (b :: k) Result: * One less superclass selection when goinng from (~) to (~#) Better for compile time and better for debugging with -ddump-simpl * The code for (~), (~~), and Coercible looks uniform, and appears together, e.g. in TysWiredIn and ClsInst.matchGlobalInst. Previously the code for (~) was different, and unique. Not only is this simpler, but it also makes the compiler a bit faster; T12227: 9% less allocation T12545: 7% less allocation This patch fixes Trac #15421
* Comments onlySimon Peyton Jones2018-07-252-5/+12
|
* Fix PrelRules.caseRules to account for out-of-range tagsSimon Peyton Jones2018-07-253-32/+67
| | | | | | | | | | | | | | | | As Trac #15436 points out, it is possible to get case dataToTag# (x :: T) of DEFAULT -> blah1 -1# -> blah2 0 -> blah3 The (-1#) alterantive is unreachable, because dataToTag# returns tags in the range [0..n-1] where n is the number of data constructors in type T. This actually made GHC crash; now we simply discard the unreachable alterantive. See Note [Unreachable caseRules alternatives] in PrelRules
* Comments onlySimon Peyton Jones2018-07-251-12/+18
|
* tc-tracing onlySimon Peyton Jones2018-07-253-3/+14
|
* Fix and document cloneWCSimon Peyton Jones2018-07-257-35/+61
| | | | | | | | | | | | | | | | | | | | The cloneWC, cloneWanted, cloneImplication family are used by * TcHoleErrors * TcRule to clone the /bindings/ in a constraint, so that solving the constraint will not add bindings to the program. The idea is only to affect unifications. But I had it wrong -- I failed to clone the EvBindsVar of an implication. That gave an assert failure, I think, as well as useless dead code. The fix is easy. I'm not adding a test case. In the type 'TcEvidence.EvBindsVar', I also renamed the 'NoEvBindsVar' constructor to 'CoEvBindsVar'. It's not that we have /no/ evidence bindings, just that we can only have coercion bindings, done via HoleDest.
* Treat isConstraintKind more consistentlySimon Peyton Jones2018-07-2513-148/+137
| | | | | | | | | | | | | | | | | | | | | | | It turned out that we were not being consistent about our use of isConstraintKind. It's delicate, because the typechecker treats Constraint and Type as /distinct/, whereas they are the /same/ in the rest of the compiler (Trac #11715). And had it wrong, which led to Trac #15412. This patch does the following: * Rename isConstraintKind to tcIsConstraintKind returnsConstraintKind to tcReturnsConstraintKind to emphasise that they use the 'tcView' view of types. * Move these functions, and some related ones (tcIsLiftedTypeKind), from Kind.hs, to group together in Type.hs, alongside isPredTy. It feels very unsatisfactory that these 'tcX' functions live in Type, but it happens because isPredTy is called later in the compiler too. But it's a consequence of the 'Constraint vs Type' dilemma.
* Improve error message on un-satisfied importSimon Peyton Jones2018-07-251-31/+48
| | | | | | | | | | | | | | | | | | Consider import M( C( a,b,c ) ) where class C is defined as module M where class C x where a :: blah c :: blah Tnen (Trac #15413) we'd like to get an error message only about failing to import C( b ), not C( a,b,c ). This was fairly easy (and local) to do. Turned out that the existing tests mod81 and mod91 are adequate tests for the feature.
* Set GenSigCtxt for the argument part of tcSubTypeSimon Peyton Jones2018-07-251-2/+30
| | | | | | | | | | | The reason for this change is described in TcUnify Note [Settting the argument context], and Trac #15438. The only effect is on error messages, where it stops GHC reporting an outright falsity (about the type signature for a function) when it finds an errors in a higher-rank situation. The testsuite changes in this patch illustrate the problem.
* Build more implicationsSimon Peyton Jones2018-07-251-8/+53
| | | | | | | | | | | | | | | | | The "non-local error" problem in Trac #14185 was due to the interaction of constraints from different function definitions. This patch makes a start towards fixing it. It adds TcUnify.alwaysBuildImplication to unconditionally build an implication in some cases, to keep the constraints from different functions separate. See the new Note [When to build an implication] in TcUnify. But a lot of error messages change, so for now I have set alwaysBuildImplication = False Result: no operational change at all. I'll get back to it!
* Clone relevant constraints to avoid side-effects on HoleDests. Fixes #15370.Matthías Páll Gissurarson2018-07-242-8/+14
| | | | | | | | | | | | | | | | | | | Summary: When looking for valid hole fits, the constraints relevant to the hole may sometimes contain a HoleDest. Previously, these were not cloned, which could cause the filling of filled coercion hole being, which would cause an assert to fail. This is now fixed. Test Plan: Regression test included. Reviewers: simonpj, bgamari, goldfire Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15370 Differential Revision: https://phabricator.haskell.org/D5004
* Remove dead code in TcUnifyKrzysztof Gogolewski2018-07-241-13/+1
| | | | | | | | | | | | | | Summary: RelaxedPolyRec is not used anymore Test Plan: validate Reviewers: bgamari, alpmestan Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4983
* Suppress -Winaccessible-code in derived codeRyan Scott2018-07-246-106/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: It's rather unfortunate that derived code can produce inaccessible code warnings (as demonstrated in #8128, #8740, and #15398), since the programmer has no control over the generated code. This patch aims to suppress `-Winaccessible-code` in all derived code. It accomplishes this by doing the following: * Generalize the `ic_env :: TcLclEnv` field of `Implication` to be of type `Env TcGblEnc TcLclEnv` instead. This way, it also captures `DynFlags`, which record the flag state at the time the `Implication` was created. * When typechecking derived code, turn off `-Winaccessible-code`. This way, any insoluble given `Implication`s that are created when typechecking this derived code will remember that `-Winaccessible-code` was disabled. * During error reporting, consult the `DynFlags` of an `Implication` before making the decision to report an inaccessible code warning. Test Plan: make test TEST="T8128 T8740 T15398" Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: monoidal, rwbarton, thomie, carter GHC Trac Issues: #8128, #8740, #15398 Differential Revision: https://phabricator.haskell.org/D4993
* Fix a nasty bug in piResultTysSimon Peyton Jones2018-07-242-12/+39
| | | | | | | | | I was failing to instantiate vigorously enough in Type.piResultTys and in the very similar function ToIface.toIfaceAppArgsX This caused Trac #15428. The fix is easy. See Note [Care with kind instantiation] in Type.hs