summaryrefslogtreecommitdiff
path: root/compiler/iface
Commit message (Collapse)AuthorAgeFilesLines
* Add PlainPanic for throwing exceptions without depending on pprintMichael Sloan2019-05-241-1/+1
| | | | | | | | | | | | | | | | | | | | | This commit splits out a subset of GhcException which do not depend on pretty printing (SDoc), as a new datatype called PlainGhcException. These exceptions can be caught as GhcException, because 'fromException' will convert them. The motivation for this change is that that the Panic module transitively depends on many modules, primarily due to pretty printing code. It's on the order of about 130 modules. This large set of dependencies has a few implications: 1. To avoid cycles / use of boot files, these dependencies cannot throw GhcException. 2. There are some utility modules that use UnboxedTuples and also use `panic`. This means that when loading GHC into GHCi, about 130 additional modules would need to be compiled instead of interpreted. Splitting the non-pprint exception throwing into a new module resolves this issue. See #13101
* Make equality constraints in kinds invisibleRyan Scott2019-05-032-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Issues #12102 and #15872 revealed something strange about the way GHC handles equality constraints in kinds: it treats them as _visible_ arguments! This causes a litany of strange effects, from strange error messages (https://gitlab.haskell.org/ghc/ghc/issues/12102#note_169035) to bizarre `Eq#`-related things leaking through to GHCi output, even without any special flags enabled. This patch is an attempt to contain some of this strangeness. In particular: * In `TcHsType.etaExpandAlgTyCon`, we propagate through the `AnonArgFlag`s of any `Anon` binders. Previously, we were always hard-coding them to `VisArg`, which meant that invisible binders (like those whose kinds were equality constraint) would mistakenly get flagged as visible. * In `ToIface.toIfaceAppArgsX`, we previously assumed that the argument to a `FunTy` always corresponding to a `Required` argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map `VisArg` to `Required` and `InvisArg` to `Inferred`. As a consequence, the iface pretty-printer correctly recognizes that equality coercions are inferred arguments, and as a result, only displays them in `-fprint-explicit-kinds` is enabled. * Speaking of iface pretty-printing, `Anon InvisArg` binders were previously being pretty-printed like `T (a :: b ~ c)`, as if they were required. This seemed inconsistent with other invisible arguments (that are printed like `T @{d}`), so I decided to switch this to `T @{a :: b ~ c}`. Along the way, I also cleaned up a minor inaccuracy in the users' guide section for constraints in kinds that was spotted in https://gitlab.haskell.org/ghc/ghc/issues/12102#note_136220. Fixes #12102 and #15872.
* Fix interface version number printing in --show-ifaceÖmer Sinan Ağacan2019-05-031-7/+8
| | | | | | | | | | | | Before Version: Wanted [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5], got [8, 0, 9, 0, 2, 0, 1, 9, 0, 4, 2, 5] After Version: Wanted 809020190425, got 809020190425
* Use funPrec, not topPrec, to parenthesize GADT argument typesRyan Scott2019-04-041-8/+13
| | | | A simple oversight. Fixes #16527.
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-253-4/+4
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-158-19/+19
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Visible dependent quantificationRyan Scott2019-03-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements GHC proposal 35 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst) by adding the ability to write kinds with visible dependent quantification (VDQ). Most of the work for supporting VDQ was actually done _before_ this patch. That is, GHC has been able to reason about kinds with VDQ for some time, but it lacked the ability to let programmers directly write these kinds in the source syntax. This patch is primarly about exposing this ability, by: * Changing `HsForAllTy` to add an additional field of type `ForallVisFlag` to distinguish between invisible `forall`s (i.e, with dots) and visible `forall`s (i.e., with arrows) * Changing `Parser.y` accordingly The rest of the patch mostly concerns adding validity checking to ensure that VDQ is never used in the type of a term (as permitting this would require full-spectrum dependent types). This is accomplished by: * Adding a `vdqAllowed` predicate to `TcValidity`. * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy` that only splits invisible `forall`s. This function is used in certain places (e.g., in instance declarations) to ensure that GHC doesn't try to split visible `forall`s (e.g., if it tried splitting `instance forall a -> Show (Blah a)`, then GHC would mistakenly allow that declaration!) This also updates Template Haskell by introducing a new `ForallVisT` constructor to `Type`. Fixes #16326. Also fixes #15658 by documenting this feature in the users' guide.
* Add AnonArgFlag to FunTySimon Peyton Jones2019-02-235-44/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big payload of this patch is: Add an AnonArgFlag to the FunTy constructor of Type, so that (FunTy VisArg t1 t2) means (t1 -> t2) (FunTy InvisArg t1 t2) means (t1 => t2) The big payoff is that we have a simple, local test to make when decomposing a type, leading to many fewer calls to isPredTy. To me the code seems a lot tidier, and probably more efficient (isPredTy has to take the kind of the type). See Note [Function types] in TyCoRep. There are lots of consequences * I made FunTy into a record, so that it'll be easier when we add a linearity field, something that is coming down the road. * Lots of code gets touched in a routine way, simply because it pattern matches on FunTy. * I wanted to make a pattern synonym for (FunTy2 arg res), which picks out just the argument and result type from the record. But alas the pattern-match overlap checker has a heart attack, and either reports false positives, or takes too long. In the end I gave up on pattern synonyms. There's some commented-out code in TyCoRep that shows what I wanted to do. * Much more clarity about predicate types, constraint types and (in particular) equality constraints in kinds. See TyCoRep Note [Types for coercions, predicates, and evidence] and Note [Constraints in kinds]. This made me realise that we need an AnonArgFlag on AnonTCB in a TyConBinder, something that was really plain wrong before. See TyCon Note [AnonTCB InivsArg] * When building function types we must know whether we need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy). This turned out to be pretty easy in practice. * Pretty-printing of types, esp in IfaceType, gets tidier, because we were already recording the (->) vs (=>) distinction in an ad-hoc way. Death to IfaceFunTy. * mkLamType needs to keep track of whether it is building (t1 -> t2) or (t1 => t2). See Type Note [mkLamType: dictionary arguments] Other minor stuff * Some tidy-up in validity checking involving constraints; Trac #16263
* Fix #16299 by deleting incorrect code from IfaceSynRyan Scott2019-02-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | GHCi's `:info` command was pretty-printing Haskell98-style data types with explicit return kinds if the return kind wasn't `Type`. This leads to bizarre output like this: ``` λ> :i (##) data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##) -- Defined in ‘GHC.Prim’ ``` Or, with unlifted newtypes: ``` λ> newtype T = MkT Int# λ> :i T newtype T :: TYPE 'IntRep = MkT Int# -- Defined at <interactive>:5:1 ``` The solution is simple: just delete one part from `IfaceSyn` where GHC mistakenly pretty-prints the return kinds for non-GADTs.
* LoadIface: Fix another CPP/Clang issueBen Gamari2018-12-221-1/+1
|
* Fix treatment of hi-boot files and dfunsSimon Peyton Jones2018-12-211-30/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #16038 exposed the fact that TcRnDriver.checkHiBootIface was creating a binding, in the module being compiled, for $fxBlah = $fBlah but $fxBlah was a /GlobalId/. But all bindings should be for /LocalIds/ else dependency analysis goes down the tubes. * I added a CoreLint check that an occurrence of a GlobalId is not bound by an binding of a LocalId. (There is already a binding-site check that no binding binds a GlobalId.) * I refactored (and actually signficantly simplified) the tricky code for dfuns in checkHiBootIface to ensure that we get LocalIds for those boot-dfuns. Alas, I then got "duplicate instance" messages when compiling HsExpr. It turns out that this is a long-standing, but extremely delicate, bug: even before this patch, if you compile HsExpr with -ddump-tc-trace, you get "duplicate instance". Without -ddump-tc-trace, it's OK. What a mess! The reason for the duplicate-instance is now explained in Note [Loading your own hi-boot file] in LoadIface. I fixed it by a Gross Hack in LoadIface.loadInterface. This is at least no worse than before. But there should be a better way. I have opened #16081 for this.
* Refine the suppression of RuntimeRep variablesSimon Peyton Jones2018-12-201-56/+77
| | | | | | | | When we pretty-print types, we suppress RuntimeRep variables, but we were being too aggressive in doing so, resulting in Trac #16074. This patch makes the suppression a bit less aggressive. See Note [Defaulting RuntimeRep variables]
* Fix #16030 by refactoring IfaceSyn's treatment of GADT constructorsRyan Scott2018-12-192-31/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: GHCi's `:info` command was pretty-printined GADT constructors suboptimally in the following ways: 1. Sometimes, fields were parenthesized when they did not need it, e.g., ```lang=haskell data Foo a where MkFoo :: (Maybe a) -> Foo a ``` I fixed this by refactoring some code in `pprIfaceConDecl` to be a little smarter with respect to GADT syntax. See `pprFieldArgTy` and `pprArgTy`. 2. With `-fprint-explicit-kinds` enabled, there would be times when specified arguments would be printed without a leading `@` in GADT return types, e.g., ```lang=haskell data Bar @k (a :: k) where MkBar :: Bar k a ``` It turns out that `ppr_tc_app`, the function which pretty-prints these return types, was not using the proper machinery to print out the arguments, which caused the visibilities to be forgotten entirely. I refactored `ppr_tc_app` to do this correctly. Test Plan: make test TEST=T16030 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #16030 Differential Revision: https://phabricator.haskell.org/D5440
* 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
View Lorry Controller Status