summaryrefslogtreecommitdiff
path: root/compiler/iface
Commit message (Collapse)AuthorAgeFilesLines
* Fix recompilation checking of pure pluginsDaniel Gröber2018-12-121-11/+48
| | | | | | | | | | | | | | | | | | | Previously when switching from using a Plugin with `RecompMaybe`/`ForceRecompile` in `pluginRecompile` to a Plugin with `NoForceRecompile` GHC would never even consider recompiling. However the previously active plugin could have modified the compilation output so we should recompile. Test Plan: validate Reviewers: bgamari, mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15858 Differential Revision: https://phabricator.haskell.org/D5299
* Support generating HIE filesAlec Theriault2018-12-111-1/+19
| | | | | | | | | | | | | | | | | | | | Adds a `-fenable-ide-info` flag which instructs GHC to generate `.hie` files (see the wiki page: https://ghc.haskell.org/trac/ghc/wiki/HIEFiles). This is a rebased version of Zubin Duggal's (@wz1000) GHC changes for his GSOC project, as posted here: https://gist.github.com/wz1000/5ed4ddd0d3e96d6bc75e095cef95363d. Test Plan: ./validate Reviewers: bgamari, gershomb, nomeata, alanz, sjakobi Reviewed By: alanz, sjakobi Subscribers: alanz, hvr, sjakobi, rwbarton, wz1000, carter Differential Revision: https://phabricator.haskell.org/D5239
* Support registering Plugins through the GHC APIDaniel Gröber2018-12-111-11/+7
| | | | | | | | | | | | | | | | | This allows tooling using the GHC API to use plugins internally. Hopefully this will make it possible to decouple the development of useful plugins from (currently) kitchen-sink type tooling projects such as ghc-mod or HIE -- at least to some extent. Test Plan: validate Reviewers: bgamari, mpickering Subscribers: mpickering, alanz, rwbarton, carter GHC Trac Issues: #15826 Differential Revision: https://phabricator.haskell.org/D5278
* Fix recompilation bug with default class methods (#15970)Simon Marlow2018-12-111-13/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a module uses a class, then it can instantiate the class and thereby use its default methods, so we must include the default methods when calculating the fingerprint for the class. Test Plan: New unit test: driver/T15970 Before: ``` =====> T15970(normal) 1 of 1 [0, 0, 0] cd "T15970.run" && $MAKE -s --no-print-directory T15970 Wrong exit code for T15970()(expected 0 , actual 2 ) Stdout ( T15970 ): Makefile:13: recipe for target 'T15970' failed Stderr ( T15970 ): C.o:function Main_zdfTypeClassMyDataType1_info: error: undefined reference to 'A_toTypedData2_closure' C.o:function Main_main1_info: error: undefined reference to 'A_toTypedData2_closure' C.o(.data+0x298): error: undefined reference to 'A_toTypedData2_closure' C.o(.data+0x480): error: undefined reference to 'A_toTypedData2_closure' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) ``` After: test passes. Reviewers: bgamari, simonpj, erikd, watashi, afarmer Subscribers: rwbarton, carter GHC Trac Issues: #15970 Differential Revision: https://phabricator.haskell.org/D5394
* Fix link name to a noteArnaud Spiwack2018-12-031-1/+1
| | | | | | | | | | Reviewers: goldfire, bgamari, tdammers Reviewed By: tdammers Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5399
* Taming the Kind Inference MonsterSimon Peyton Jones2018-11-293-40/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881
* Fix #15941 by only special-casing visible infix applicationsRyan Scott2018-11-261-5/+23
| | | | | | | | | | | | | | | | | | | | | | | | Summary: The iface pretty-printer had a special case for an application of an infix type constructor to two arguments. But this didn't take the visibilities of the arguments into account, which could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when `-fprint-explicit-kinds` was enabled (#15941). The fix is relatively straightforward: simply plumb through the visibilities of each argument, and only trigger the special case for infix applications if both arguments are visible (i.e., required). Test Plan: make test TEST=T15941 Reviewers: goldfire, bgamari, monoidal Reviewed By: goldfire, monoidal Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15941 Differential Revision: https://phabricator.haskell.org/D5375
* Print explicit foralls in type family eqns when appropriateRyan Scott2018-11-262-22/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When `-fprint-explicit-foralls` is enabled, type family equations are either printed without an explict `forall` entirely, or with a bizarre square bracket syntax (in the case of closed type families). I find neither satisfying, so in this patch, I introduce support for printing explicit `forall`s in open type-family, closed type-family, and data-family equations when appropriate. (By "when appropriate", I refer to the conditions laid out in `Note [When to print foralls]` in `IfaceType`.) One tricky point in the implementation is that I had to pick a visibility for each type variable in a `CoAxiom`/`FamInst` in order to be able to pass it to `pprUserIfaceForAll` //et al.// Because the type variables in a type family instance equation can't be instantiated by the programmer anyway, the choice only really matters for pretty-printing purposes, so I simply went with good ol' trustworthy `Specified`. (This design choice is documented in `Note [Printing foralls in type family instances]` in `IfaceType`.) Test Plan: make test TEST=T15827 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15827 Differential Revision: https://phabricator.haskell.org/D5282
* Overhaul -fprint-explicit-kinds to use VKARyan Scott2018-11-223-91/+147
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the behavior of `-fprint-explicit-kinds` so that it displays kind argument using visible kind application. In other words, the flag now: 1. Prints instantiations of specified variables with `@(...)`. 2. Prints instantiations of inferred variables with `@{...}`. In addition, this patch removes the `Use -fprint-explicit-kinds to see the kind arguments` error message that often arises when a type mismatch occurs due to different kinds. Instead, whenever there is a kind mismatch, we now enable the `-fprint-explicit-kinds` flag locally to help cue to the programmer where the error lies. (See `Note [Kind arguments in error messages]` in `TcErrors`.) As a result, these funny `@{...}` things can now appear to the user even without turning on the `-fprint-explicit-kinds` flag explicitly, so I took the liberty of documenting them in the users' guide. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15871 Differential Revision: https://phabricator.haskell.org/D5314
* Fix #15852 by eta expanding data family instance RHSes, tooRyan Scott2018-11-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | When I defined `etaExpandFamInstLHS`, I blatantly forgot to eta expand the RHSes of data family instances. (Actually, I claimed that they didn't //need// to be eta expanded. I'm not sure what I was thinking.) This fixes the issue by changing `etaExpandFamInstLHS` to `etaExpandFamInst` and, well, making it actually eta expand the RHS. Test Plan: make test TEST=T15852 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15852 Differential Revision: https://phabricator.haskell.org/D5328
* Smarter HsType pretty-print for promoted dataconsSimon Peyton Jones2018-11-153-30/+28
| | | | | | | | | | | | | | | | | | | | | Fix Trac #15898, by being smarter about when to print a space before a promoted data constructor, in a HsType. I had to implement a mildly tiresome function HsType.lhsTypeHasLeadingPromotionQuote It has multiple cases, of course, but it's very simple. The patch improves the error-message output in a bunch of cases, and (to my surprise) actually fixes a bug in the output of T14343 (Trac #14343), thus - In the expression: _ :: Proxy '('( 'True, 'False), 'False) + In the expression: _ :: Proxy '( '( 'True, 'False), 'False) I discovered that there were two copies of the PromotionFlag type (a boolean, with helpfully named data cons), one in IfaceType and one in HsType. So I combined into one, PromotionFlag, and moved it to BasicTypes. That's why quite a few files are touched, but it's all routine.
* Fix embarrassing, egregious bug in roles of (->)Richard Eisenberg2018-11-011-1/+1
| | | | | | | | | | | | | | Previously, I had inexplicably decided that (->)'s roles were all Representational. But, of course, its first two parameters are *dependent* RuntimeReps. All dependent parameters have a Nominal role, because all roles in kinds are Nominal. Fix is easy, but I have no idea how the world hasn't come crashing down before now. This was found while investigating #15801, which requires visible type application in types to observe. Hence, the test case will come with the main patch for #12045.
* Improve generated `GHC.Prim` docsAlec Theriault2018-10-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: * Extended `genprimcode` to generate Haddock-compatible deprecations, as well as displaying information about which functions are LLVM-only and which functions can fail with an unchecked exception. * Ported existing deprecations to the new format, and also added a deprecation on `par#` (see Trac #15227). * Emit an error on fixity/deprecation of builtins, unless we are processing the module in which that name is defined (see Trac #15233). That means the following is no longer accepted (outside of `GHC.Types`): ``` infixr 7 : {-# DEPRECATED (:) "cons is deprecated" #-} ``` * Generate `data (->) a b` with docs and fixity in `GHC.Prim`. This means: GHC can now parse `data (->) a b` and `infixr 0 ->` (only in `GHC.Prim`) and `genprimcode` can digest `primtype (->) a b` (See Trac #4861) as well as some misc fixes along the way. Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, mpickering, carter GHC Trac Issues: #15227, #15233, #4861 Differential Revision: https://phabricator.haskell.org/D5167
* Better pretty-printing of forall typesSimon Peyton Jones2018-10-041-6/+7
| | | | | | | | | | Currently forall-types with a lot of type variables, or type variables with big kinds, are pretty-printed too horizontally, and dribble off to the right in an illegible way. This patch treats the type variables as a group, and uses 'fsep' to lay them out decently.
* Drop GHC 8.2 compatibilityRyan Scott2018-10-031-3/+0
| | | | | | | | | | | | | | | | | Summary: GHC 8.6.1 is out, so now GHC's support window only extends back to GHC 8.4. This means we can delete gobs of code that were only used for GHC 8.2 support. Hooray! Test Plan: ./validate Reviewers: bgamari, Phyx, erikd Reviewed By: bgamari, Phyx Subscribers: rwbarton, erikd, carter Differential Revision: https://phabricator.haskell.org/D5192
* Coercion Quantificationningning2018-09-158-124/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch corresponds to #15497. According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2, we would like to have coercion quantifications back. This will allow us to migrate (~#) to be homogeneous, instead of its current heterogeneous definition. This patch is (lots of) plumbing only. There should be no user-visible effects. An overview of changes: - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables, but only in *Core*. All relevant functions are updated accordingly. - Small changes that should be irrelevant to the main task: 1. removed dead code `mkTransAppCo` in Coercion 2. removed out-dated Note Computing a coercion kind and roles in Coercion 3. Added `Eq4` in Note Respecting definitional equality in TyCoRep, and updated `mkCastTy` accordingly. 4. Various updates and corrections of notes and typos. - Haddock submodule needs to be changed too. Acknowledgments: This work was completed mostly during Ningning Xie's Google Summer of Code, sponsored by Google. It was advised by Richard Eisenberg, supported by NSF grant 1704041. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar Subscribers: RyanGlScott, monoidal, rwbarton, carter GHC Trac Issues: #15497 Differential Revision: https://phabricator.haskell.org/D5054
* Comments only (on IfDataInstance)Simon Peyton Jones2018-09-131-4/+6
|
* Fix the __GLASGOW_HASKELL__ comparisonKrzysztof Gogolewski2018-08-301-3/+2
| | | | | | | | | | | | | | | | | Summary: GHC 8.4 corresponds to 804, not 840. Found by Gabor Greif. Test Plan: Harbormaster Reviewers: ggreif, bgamari, mpickering Reviewed By: ggreif Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5064
* Add comments about pretty-printing via IfaceSynSimon Peyton Jones2018-08-242-25/+4
| | | | | Provoked by discussion on Phab:D5097 (Trac #15546), I'm adding a big Note explaing the strategy of pretty-printing via IfaceSyn
* Turn infinite loop into a panicSimon Peyton Jones2018-08-221-3/+12
| | | | | | | | | | | | | | In these two functions * TcIface.toIfaceAppTyArgsX * Type.piResultTys we take a type application (f t1 .. tn) and try to find its kind. It turned out that, if (f t1 .. tn) was ill-kinded the function would go into an infinite loop. That's not good: it caused the loop in Trac #15473. This patch doesn't fix the bug in #15473, but it does turn the loop into a decent panic, which is a step forward.
* Replace most occurences of foldl with foldl'.klebinger.andreas@gmx.at2018-08-213-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds foldl' to GhcPrelude and changes must occurences of foldl to foldl'. This leads to better performance especially for quick builds where GHC does not perform strictness analysis. It does change strictness behaviour when we use foldl' to turn a argument list into function applications. But this is only a drawback if code looks ONLY at the last argument but not at the first. And as the benchmarks show leads to fewer allocations in practice at O2. Compiler performance for Nofib: O2 Allocations: -1 s.d. ----- -0.0% +1 s.d. ----- -0.0% Average ----- -0.0% O2 Compile Time: -1 s.d. ----- -2.8% +1 s.d. ----- +1.3% Average ----- -0.8% O0 Allocations: -1 s.d. ----- -0.2% +1 s.d. ----- -0.1% Average ----- -0.2% Test Plan: ci Reviewers: goldfire, bgamari, simonmar, tdammers, monoidal Reviewed By: bgamari, monoidal Subscribers: tdammers, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4929
* --show-iface: Qualify all non-local namesSimon Jakobi2018-08-121-1/+17
| | | | | | | | | | | | | | | | | | | | 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
* Fix typosKrzysztof Gogolewski2018-08-051-1/+1
|
* Plugin dependency information is stored separatelyChristiaan Baaij2018-08-011-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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-011-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a nasty bug in piResultTysSimon Peyton Jones2018-07-241-4/+4
| | | | | | | | | 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
* Fix space leaksSimon Marlow2018-07-161-3/+4
| | | | | | | | | | | | | | | | | | | | | Summary: All these were detected by -fghci-leak-check when GHC was compiled *without* optimisation (e.g. using the "quick" build flavour). Unfortunately I don't know of a good way to keep this working. I'd like to just disable the -fghci-leak-check flag when the compiler is built without optimisation, but it doesn't look like we have an easy way to do that. And even if we could, it would be fragile anyway, Test Plan: `cd testsuite/tests/ghci; make` Reviewers: bgamari, hvr, erikd, tdammers Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #15246 Differential Revision: https://phabricator.haskell.org/D4872
* Add flag to show docs of valid hole fitsMatthías Páll Gissurarson2018-07-121-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One issue with valid hole fits is that the function names can often be opaque for the uninitiated, such as `($)`. This diff adds a new flag, `-fshow-docs-of-hole-fits` that adds the documentation of the identifier in question to the message, using the same mechanism as the `:doc` command. As an example, with this flag enabled, the valid hole fits for `_ :: [Int] -> Int` will include: ``` Valid hole fits include head :: forall a. [a] -> a {-^ Extract the first element of a list, which must be non-empty.-} with head @Int (imported from ‘Prelude’ (and originally defined in ‘GHC.List’)) ``` And one of the refinement hole fits, `($) _`, will read: ``` Valid refinement hole fits include ... ($) (_ :: [Int] -> Int) where ($) :: forall a b. (a -> b) -> a -> b {-^ Application operator. This operator is redundant, since ordinary application @(f x)@ means the same as @(f '$' x)@. However, '$' has low, right-associative binding precedence, so it sometimes allows parentheses to be omitted; for example: > f $ g $ h x = f (g (h x)) It is also useful in higher-order situations, such as @'map' ('$' 0) xs@, or @'Data.List.zipWith' ('$') fs xs@. Note that @($)@ is levity-polymorphic in its result type, so that foo $ True where foo :: Bool -> Int# is well-typed-} with ($) @'GHC.Types.LiftedRep @[Int] @Int (imported from ‘Prelude’ (and originally defined in ‘GHC.Base’)) ``` Another example of where documentation can come in very handy, is when working with the `lens` library. When you compile ``` {-# OPTIONS_GHC -fno-show-provenance-of-hole-fits -fshow-docs-of-hole-fits #-} module LensDemo where import Control.Lens import Control.Monad.State newtype Test = Test { _value :: Int } deriving (Show) value :: Lens' Test Int value f (Test i) = Test <$> f i updTest :: Test -> Test updTest t = t &~ do _ value (1 :: Int) ``` You get: ``` Valid hole fits include (#=) :: forall s (m :: * -> *) a b. MonadState s m => ALens s s a b -> b -> m () {-^ A version of ('Control.Lens.Setter..=') that works on 'ALens'.-} with (#=) @Test @(StateT Test Identity) @Int @Int (<#=) :: forall s (m :: * -> *) a b. MonadState s m => ALens s s a b -> b -> m b {-^ A version of ('Control.Lens.Setter.<.=') that works on 'ALens'.-} with (<#=) @Test @(StateT Test Identity) @Int @Int (<*=) :: forall s (m :: * -> *) a. (MonadState s m, Num a) => LensLike' ((,) a) s a -> a -> m a {-^ Multiply the target of a numerically valued 'Lens' into your 'Monad''s state and return the result. When you do not need the result of the multiplication, ('Control.Lens.Setter.*=') is more flexible. @ ('<*=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a ('<*=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a @-} with (<*=) @Test @(StateT Test Identity) @Int (<+=) :: forall s (m :: * -> *) a. (MonadState s m, Num a) => LensLike' ((,) a) s a -> a -> m a {-^ Add to the target of a numerically valued 'Lens' into your 'Monad''s state and return the result. When you do not need the result of the addition, ('Control.Lens.Setter.+=') is more flexible. @ ('<+=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a ('<+=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a @-} with (<+=) @Test @(StateT Test Identity) @Int (<-=) :: forall s (m :: * -> *) a. (MonadState s m, Num a) => LensLike' ((,) a) s a -> a -> m a {-^ Subtract from the target of a numerically valued 'Lens' into your 'Monad''s state and return the result. When you do not need the result of the subtraction, ('Control.Lens.Setter.-=') is more flexible. @ ('<-=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a ('<-=') :: ('MonadState' s m, 'Num' a) => 'Control.Lens.Iso.Iso'' s a -> a -> m a @-} with (<-=) @Test @(StateT Test Identity) @Int (<<*=) :: forall s (m :: * -> *) a. (MonadState s m, Num a) => LensLike' ((,) a) s a -> a -> m a {-^ Modify the target of a 'Lens' into your 'Monad''s state by multipling a value and return the /old/ value that was replaced. When you do not need the result of the operation, ('Control.Lens.Setter.*=') is more flexible. @ ('<<*=') :: ('MonadState' s m, 'Num' a) => 'Lens'' s a -> a -> m a ('<<*=') :: ('MonadState' s m, 'Num' a) => 'Iso'' s a -> a -> m a @-} with (<<*=) @Test @(StateT Test Identity) @Int (Some hole fits suppressed; use -fmax-valid-hole-fits=N or -fno-max-valid-hole-fits) ``` Which allows you to see at a glance what opaque operators like `(<<*=)` and `(<#=)` do. Reviewers: bgamari, sjakobi Reviewed By: sjakobi Subscribers: sjakobi, alexbiehl, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4848
* Use IfaceAppArgs to store an IfaceAppTy's argumentsRyan Scott2018-07-116-152/+237
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, an `IfaceAppTy` has no way to tell whether its argument is visible or not, so it simply treats all arguments as visible, leading to #15330. We already have a solution for this problem in the form of the `IfaceTcArgs` data structure, used by `IfaceTyConApp` to represent the arguments to a type constructor. Therefore, it makes sense to reuse this machinery for `IfaceAppTy`, so this patch does just that. This patch: 1. Renames `IfaceTcArgs` to `IfaceAppArgs` to reflect its more general purpose. 2. Changes the second field of `IfaceAppTy` from `IfaceType` to `IfaceAppArgs`, and propagates the necessary changes through. In particular, pretty-printing an `IfaceAppTy` now goes through the `IfaceAppArgs` pretty-printer, which correctly displays arguments as visible or not for free, fixing #15330. 3. Changes `toIfaceTypeX` and related functions so that when converting an `AppTy` to an `IfaceAppTy`, it flattens as many argument `AppTy`s as possible, and then converts those arguments into an `IfaceAppArgs` list, using the kind of the function `Type` as a guide. (Doing so minimizes the number of times we need to call `typeKind`, which is more expensive that finding the kind of a `TyCon`.) Test Plan: make test TEST=T15330 Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15330 Differential Revision: https://phabricator.haskell.org/D4938
* Refactor coercion ruleningning2018-07-094-48/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The patch is an attempt on #15192. It defines a new coercion rule ``` | GRefl Role Type MCoercion ``` which correspondes to the typing rule ``` t1 : k1 ------------------------------------ GRefl r t1 MRefl: t1 ~r t1 t1 : k1 co :: k1 ~ k2 ------------------------------------ GRefl r t1 (MCo co) : t1 ~r t1 |> co ``` MCoercion wraps a coercion, which might be reflexive (MRefl) or not (MCo co). To know more about MCoercion see #14975. We keep Refl ty as a special case for nominal reflexive coercions, naemly, Refl ty :: ty ~n ty. This commit is meant to be a general performance improvement, but there are a few regressions. See #15192, comment:13 for more information. Test Plan: ./validate Reviewers: bgamari, goldfire, simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15192 Differential Revision: https://phabricator.haskell.org/D4747
* Make ppr_tc_args aware of -fprint-explicit-kindsRyan Scott2018-07-051-2/+6
| | | | | | | | | | | | | | | | | | Summary: `ppr_tc_args` was printing invisible kind arguments even when `-fprint-explicit-kinds` wasn't enabled. Easily fixed. Test Plan: make test TEST=T15341 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15341 Differential Revision: https://phabricator.haskell.org/D4932
* Fix #15308 by suppressing invisble args more rigorouslyRyan Scott2018-07-051-1/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: There was a buglet in `stripInvisArgs` (which is part of the pretty-printing pipeline for types) in which only invisble arguments which came before any visible arguments would be suppressed, but any invisble arguments that came //after// visible ones would still be printed, even if `-fprint-explicit-kinds` wasn't enabled. The fix is simple: make `stripInvisArgs` recursively process the remaining types even after a visible argument is encountered. Test Plan: make test TEST=T15308 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15308 Differential Revision: https://phabricator.haskell.org/D4891
* More misc commentsSimon Peyton Jones2018-06-251-6/+9
| | | | | ... plus, reorder equations in toIfaceVar to improve legibility. No change in behaviour.
* Typofixes in docs and comments [ci skip]Gabor Greif2018-06-181-1/+1
|
* Built-in Natural literals in CoreSylvain Henry2018-06-151-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for built-in Natural literals in Core. - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber constructor with a LitNumType field - Support built-in Natural literals - Add desugar warning for negative literals - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency reasons This patch introduces only a few rules for Natural literals (compared to Integer's rules). Factorization of the built-in rules for numeric literals will be done in another patch as this one is already big to review. Test Plan: validate test build with integer-simple Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar Reviewed By: bgamari Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton, thomie GHC Trac Issues: #14170, #14465 Differential Revision: https://phabricator.haskell.org/D4212
* Embrace -XTypeInType, add -XStarIsTypeVladislav Zavialov2018-06-141-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implement the "Embrace Type :: Type" GHC proposal, .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst GHC 8.0 included a major change to GHC's type system: the Type :: Type axiom. Though casual users were protected from this by hiding its features behind the -XTypeInType extension, all programs written in GHC 8+ have the axiom behind the scenes. In order to preserve backward compatibility, various legacy features were left unchanged. For example, with -XDataKinds but not -XTypeInType, GADTs could not be used in types. Now these restrictions are lifted and -XTypeInType becomes a redundant flag that will be eventually deprecated. * Incorporate the features currently in -XTypeInType into the -XPolyKinds and -XDataKinds extensions. * Introduce a new extension -XStarIsType to control how to parse * in code and whether to print it in error messages. Test Plan: Validate Reviewers: goldfire, hvr, bgamari, alanz, simonpj Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15195 Differential Revision: https://phabricator.haskell.org/D4748
* Fix `print-explicit-runtime-reps` (#11786).HE, Tao2018-06-081-3/+22
| | | | | | | | | | | | | | By fixing splitting of IfaceTypes in splitIfaceSigmaTy. Test Plan: make test TEST="T11549 T11376 T11786" Reviewers: goldfire, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11786, #11376 Differential Revision: https://phabricator.haskell.org/D4733
* Fix unparseable pretty-printing of promoted data consAndreas Herrmann2018-06-071-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we would print code which would not round-trip: ``` > :set -XDataKinds > :set -XPolyKinds > data Proxy k = Proxy > _ :: Proxy '[ 'True ] error: Found hole: _ :: Proxy '['True] > _ :: Proxy '['True] error: Invalid type signature: _ :: ... Should be of form <variable> :: <type> ``` Test Plan: Validate with T14343 Reviewers: RyanGlScott, goldfire, bgamari, tdammers Reviewed By: RyanGlScott, bgamari Subscribers: tdammers, rwbarton, thomie, carter GHC Trac Issues: #14343 Differential Revision: https://phabricator.haskell.org/D4746
* Serialize docstrings to ifaces, display them with new GHCi :doc commandSimon Jakobi2018-06-042-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | If `-haddock` is set, we now extract docstrings from the renamed ast and serialize them in the .hi-files. This includes some of the changes from D4749 with the notable exceptions of the docstring lexing and renaming. A currently limited and experimental GHCi :doc command can be used to display docstrings for declarations. The formatting of pretty-printed docstrings is changed slightly, causing some changes in testsuite/tests/haddock. Test Plan: ./validate Reviewers: alexbiehl, hvr, gershomb, harpocrates, bgamari Reviewed By: alexbiehl Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4758
* Provide `getWithUserData` and `putWithUserData`Matthew Pickering2018-06-041-7/+26
| | | | | | | | | | | | | | | | | | | | | Summary: This makes it possible to serialise Names and FastStrings in user programs, for example, when writing a source plugin. When writing my first source plugin, I wanted to serialise names but it wasn't possible easily without exporting additional constructors. This interface is sufficient and abstracts nicely over the symbol table and dictionary. Reviewers: alpmestan, bgamari Reviewed By: alpmestan Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15223 Differential Revision: https://phabricator.haskell.org/D4782
* Extended the plugin system to run plugins on more representationsBoldizsar Nemeth2018-06-021-1/+4
| | | | | | | | | | | | | | | | | | | | Extend GHC plugins to access parsed, type checked representation, interfaces that are loaded. And splices that are evaluated. The goal is to enable development tools to access the GHC representation in the pre-existing build environment. See the full proposal here: https://ghc.haskell.org/trac/ghc/wiki/ExtendedPluginsProposal Reviewers: goldfire, bgamari, ezyang, angerman, mpickering Reviewed By: mpickering Subscribers: ezyang, angerman, mpickering, ulysses4ever, rwbarton, thomie, carter GHC Trac Issues: #14709 Differential Revision: https://phabricator.haskell.org/D4342
* vectorise: Put it out of its miseryBen Gamari2018-06-025-187/+6
| | | | | | | | | | | | | | | | | | | | | Poor DPH and its vectoriser have long been languishing; sadly it seems there is little chance that the effort will be rekindled. Every few years we discuss what to do with this mass of code and at least once we have agreed that it should be archived on a branch and removed from `master`. Here we do just that, eliminating heaps of dead code in the process. Here we drop the ParallelArrays extension, the vectoriser, and the `vector` and `primitive` submodules. Test Plan: Validate Reviewers: simonpj, simonmar, hvr, goldfire, alanz Reviewed By: simonmar Subscribers: goldfire, rwbarton, thomie, mpickering, carter Differential Revision: https://phabricator.haskell.org/D4761
* Implement "An API for deciding whether plugins should cause recompilation"Matthew Pickering2018-05-302-2/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the API proposed as pull request #108 for plugin authors to influence the recompilation checker. It adds a new field to a plugin which computes a `FingerPrint`. This is recorded in interface files and if it changes then we recompile the module. There are also helper functions such as `purePlugin` and `impurePlugin` for constructing plugins which have simple recompilation semantics but in general, an author can compute a hash as they wish. Fixes #12567 and #7414 https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002 2-plugin-recompilation.rst Reviewers: bgamari, ggreif Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #7414, #12567 Differential Revision: https://phabricator.haskell.org/D4366
* Fix GHCi space leaks (#15111)Simon Marlow2018-05-171-1/+51
| | | | | | | | | | | | | | | | | Summary: There were a number of leaks causing previously loaded modules to be retained after a new `:load`. This fixes enough leaks to get the tests to pass from D4658. Test Plan: See new tests in D4658 Reviewers: niteria, bgamari, simonpj, erikd Subscribers: thomie, carter GHC Trac Issues: #15111 Differential Revision: https://phabricator.haskell.org/D4659
* Fix #15039 by pretty-printing equalities more systematicallyRyan Scott2018-05-161-38/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHC previously had a handful of special cases for pretty-printing equalities in a more user-friendly manner, but they were far from comprehensive (see #15039 for an example of where this fell apart). This patch makes the pretty-printing of equalities much more systematic. I've adopted the approach laid out in https://ghc.haskell.org/trac/ghc/ticket/15039#comment:4, and updated `Note [Equality predicates in IfaceType]` accordingly. We are now more careful to respect the properties of the `-fprint-explicit-kinds` and `-fprint-equality-relations` flags, which led to some improvements in error message outputs. Along the way, I also tweaked the error-reporting machinery not to print out the type of a typed hole when the type is an unlifted equality, since it's kind (`TYPE ('TupleRep '[])`) was more confusing than anything. Test Plan: make test TEST="T15039a T15039b T15039c T15039d" Reviewers: simonpj, goldfire, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15039 Differential Revision: https://phabricator.haskell.org/D4696
* Less Tc inside simplCore (Phase 1 for #14391)Artem Pelenitsyn2018-05-152-30/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplifier depends on typechecker in two points: `thNameToGhcName` (`lookupThName_maybe`, in particular) and `lookupGlobal`. We want to cut the ties in two steps. 1. (Presented in this commit), reimplement both functions in a way that doesn't use typechecker. 2. (Should follow), do code moving: a) `lookupGlobal` should go in some typechecker-free place; b) `thNameToGhcName` should leave simplifier, because it is not used there at all (probably, it should be placed somewhere where `GhcPlugins` can see it -- this is suggested by Joachim on Trac). Details ======= We redesigned lookup interface a bit so that it exposes some `IO`-equivalents of `Tc`-features in use. First, `CoreMonad.hs` still calls `lookupGlobal` which is no longer bound to the typechecker monad, but still resides in `TcEnv.hs` — it should be moved out of Tc-land at some point (“Phase 2”) in the future in order to achieve its part of the #14391's goal. Second, `lookupThName_maybe` is eliminated from `CoreMonad.hs` completely; this already achieves its part of the goal of #14391. Its client, though, `thNameToGhcName`, is better to be moved in the future also, for it is not used in the `CoreMonad.hs` (or anywhere else) anyway. Joachim suggested “any module reexported by GhcPlugins (or maybe even that module itself)”. As a side goal, we removed `initTcForLookup` which was instrumental for the past version of `lookupGlobal`. This, in turn, called for pushing some more parts of the lookup interface from the `Tc`-monad to `IO`, most notably, adding `IO`-version of `lookupOrig` and pushing `dataConInfoPtrToName` to `IO`. The `lookupOrig` part, in turn, triggered a slight redesign of name cache updating interface: we now have both, `updNameCacheIO` and `updNameCacheTc`, both accepting `mod` and `occ` to force them inside, instead of more error-prone outside before. But all these hardly have to do anything with #14391, mere refactoring. Reviewers: simonpj, nomeata, bgamari, hvr Reviewed By: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14391 Differential Revision: https://phabricator.haskell.org/D4503
* Fix #14875 by introducing PprPrec, and using itRyan Scott2018-05-132-64/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trying to determine when to insert parentheses during TH conversion is a bit of a mess. There is an assortment of functions that try to detect this, such as: * `hsExprNeedsParens` * `isCompoundHsType` * `hsPatNeedsParens` * `isCompoundPat` * etc. To make things worse, each of them have slightly different semantics. Plus, they don't work well in the presence of explicit type signatures, as #14875 demonstrates. All of these problems can be alleviated with the use of an explicit precedence argument (much like what `showsPrec` currently does). To accomplish this, I introduce a new `PprPrec` data type, and define standard predences for things like function application, infix operators, function arrows, and explicit type signatures (that last one is new). I then added `PprPrec` arguments to the various `-NeedsParens` functions, and use them to make smarter decisions about when things need to be parenthesized. A nice side effect is that functions like `isCompoundHsType` are now completely unneeded, since they're simply aliases for `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring to remove these sorts of functions. I also did a pass over various utility functions in GHC for constructing AST forms and used more appropriate precedences where convenient. Along the way, I also ripped out the existing `TyPrec` data type (which was tailor-made for pretty-printing `Type`s) and replaced it with `PprPrec` for consistency. Test Plan: make test TEST=T14875 Reviewers: alanz, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14875 Differential Revision: https://phabricator.haskell.org/D4688
* Caching coercion roles in NthCo and coercionKindsRole refactoringTobias Dammers2018-04-202-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While addressing nonlinear behavior related to coercion roles, particularly `NthCo`, we noticed that coercion roles are recalculated often even though they should be readily at hand already in most cases. This patch adds a `Role` to the `NthCo` constructor so that we can cache them rather than having to recalculate them on the fly. https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the approach. Performance improvement over GHC HEAD, when compiling Grammar.hs (see below): GHC 8.2.1: ``` ghc Grammar.hs 176.27s user 0.23s system 99% cpu 2:56.81 total ``` before patch (but with other optimizations applied): ``` ghc Grammar.hs -fforce-recomp 175.77s user 0.19s system 100% cpu 2:55.78 total ``` after: ``` ../../ghc/inplace/bin/ghc-stage2 Grammar.hs 10.32s user 0.17s system 98% cpu 10.678 total ``` Introduces the following regressions: - perf/compiler/parsing001 (possibly false positive) - perf/compiler/T9872 - perf/compiler/haddock.base Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #11735 Differential Revision: https://phabricator.haskell.org/D4394
* Fix #14238 by always pretty-printing visible tyvarsRyan Scott2018-04-071-1/+36
| | | | | | | | | | | | | | | | | | | Summary: Before, GHC would never print visible tyvars in the absence of `-fprint-explicit-foralls`, which led to `:kind` displaying incorrect kinds in GHCi. The fix is simple—simply check beforehand if any of the type variable binders are required when deciding when to pretty-print them. Test Plan: make test TEST=T14238 Reviewers: simonpj, goldfire, bgamari Subscribers: thomie, carter GHC Trac Issues: #14238 Differential Revision: https://phabricator.haskell.org/D4564
* Track type variable scope more carefully.Richard Eisenberg2018-03-312-13/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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}
View Lorry Controller Status