summaryrefslogtreecommitdiff
path: root/compiler/hsSyn/HsUtils.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* ApplicativeDo: handle BodyStmt (#12143)Simon Marlow2017-10-271-1/+1
| | | | | | | | | | | | | | | | | | | Summary: It's simple to treat BodyStmt just like a BindStmt with a wildcard pattern, which is enough to fix #12143 without going all the way to using `<*` and `*>` (#10892). Test Plan: * new test cases in `ado004.hs` * validate Reviewers: niteria, simonpj, bgamari, austin, erikd Subscribers: rwbarton, thomie GHC Trac Issues: #12143 Differential Revision: https://phabricator.haskell.org/D4128
* Remove m_type from Match (#14313)Joachim Breitner2017-10-041-2/+1
| | | | | | | this is a remains from supporting Result Type Signaturs in the ancient past. Differential Revision: https://phabricator.haskell.org/D4066
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | This switches the compiler/ component to get compiled with -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all modules. This is motivated by the upcoming "Prelude" re-export of `Semigroup((<>))` which would cause lots of name clashes in every modulewhich imports also `Outputable` Reviewers: austin, goldfire, bgamari, alanz, simonmar Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari Differential Revision: https://phabricator.haskell.org/D3989
* Refactor type family instance abstract syntax declarationsRyan Scott2017-08-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements @simonpj's suggested refactoring of the abstract syntax for type/data family instances (from https://ghc.haskell.org/trac/ghc/ticket/14131#comment:9). This combines the previously separate `TyFamEqn` and `DataFamInstDecl` types into a single `FamEqn` datatype. This also factors the `HsImplicitBndrs` out of `HsTyPats` in favor of putting them just outside of `FamEqn` (as opposed to before, where all of the implicit binders were embedded inside of `TyFamEqn`/`DataFamInstDecl`). Finally, along the way I noticed that `dfid_fvs` and `tfid_fvs` were completely unused, so I removed them. Aside from some changes in parser test output, there is no change in behavior. Requires a Haddock submodule commit from my fork (at https://github.com/RyanGlScott/haddock/commit/815d2deb9c0222c916becccf84 64b740c26255fd) Test Plan: ./validate Reviewers: simonpj, austin, goldfire, bgamari, alanz Reviewed By: bgamari Subscribers: mpickering, goldfire, rwbarton, thomie, simonpj GHC Trac Issues: #14131 Differential Revision: https://phabricator.haskell.org/D3881
* Revise function arity mismatch errors involving TypeApplicationsRyan Scott2017-08-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, whenever you apply a function to too many arguments and some of those arguments happen to be visible type applications, the error message that GHC gives is rather confusing. Consider the message you receive when typechecking `id @Int 1 2`: ``` The function `id` is applied to three arguments, but its type `Int -> Int` has only one ``` This is baffling, since the two lines treat the visible type argument `@Int` differently. The top line ("applied to three arguments") includes `@Int`, whereas the bottom line ("has only one") excludes `@Int` from consideration. There are multiple ways one could fix this, which I explain in an addendum to `Note [Herald for matchExpectedFunTys]`. The approach adopted here is to change the herald of this error message to include visible type arguments, and to avoid counting them in the "applied to n arguments" part of the error. The end result is that the new error message for `id @Int 1 2` is now: ``` The expression `id @Int` is applied to two arguments, but its type `Int -> Int` has only one ``` Test Plan: make test TEST=T13902 Reviewers: goldfire, austin, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie GHC Trac Issues: #13902 Differential Revision: https://phabricator.haskell.org/D3868
* Use field names for all uses of datacon MatchSimon Peyton Jones2017-07-311-3/+6
| | | | | | | This is refactoring only... elimiante all positional uses of the data constructor Match in favour of field names. No change in behaviour.
* Reject top-level banged bindingsSimon Peyton Jones2017-07-311-6/+10
| | | | | | | | | | | | | | | Bizarrely, we were not rejecting !x = e Fix: * In the test in DsBinds.dsTopLHsBinds, use isBangedHsBind, not isBangedPatBind. (Indeed the latter dies altogther.) * Implement isBangedHsBind in HsUtils; be sure to handle AbsBinds All this was shown up by Trac #13594
* Improve the desugaring of -XStrictSimon Peyton Jones2017-07-311-47/+29
| | | | | | | | | | | | | | | | | | | | | | | Trac #14035 showed that -XStrict was generating some TERRIBLE desugarings, espcially for bindings with INLINE pragmas. Reason: with -XStrict, all AbsBinds (even for non-recursive functions) went via the general-case deguaring for AbsBinds, namely "generate a tuple and select from it", even though in this case there was only one variable in the tuple. And that in turn interacts terribly badly with INLINE pragmas. This patch cleans things up: * I killed off AbsBindsSig completely, in favour of a boolean flag abs_sig in AbsBinds. See Note [The abs_sig field of AbsBinds] This allowed me to delete lots of code; and instance-method declarations can enjoy the benefits too. (They could have before, but no one had changed them to use AbsBindsSig.) * I refactored all the AbsBinds handling in DsBinds into a new function DsBinds.dsAbsBinds. This allowed me to handle the strict case uniformly
* Refactoring around FunRhsSimon Peyton Jones2017-07-311-1/+3
| | | | | * Clarify the comments around the mc_strictness field of FunRhs * Use record field names consistently for FunRhs
* Treat banged bindings as FunBindsBen Gamari2017-06-271-3/+12
| | | | | | | | | | | | | | | This is another attempt at resolving #13594 by treating strict variable binds as FunBinds instead of PatBinds (as suggested in comment:1). Test Plan: Validate Reviewers: austin, alanz Subscribers: rwbarton, thomie, mpickering GHC Trac Issues: #13594 Differential Revision: https://phabricator.haskell.org/D3670
* Udate hsSyn AST to use Trees that GrowAlan Zimmerman2017-06-061-145/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: See https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow This commit prepares the ground for a full extensible AST, by replacing the type parameter for the hsSyn data types with a set of indices into type families, data GhcPs -- ^ Index for GHC parser output data GhcRn -- ^ Index for GHC renamer output data GhcTc -- ^ Index for GHC typechecker output These are now used instead of `RdrName`, `Name` and `Id`/`TcId`/`Var` Where the original name type is required in a polymorphic context, this is accessible via the IdP type family, defined as type family IdP p type instance IdP GhcPs = RdrName type instance IdP GhcRn = Name type instance IdP GhcTc = Id These types are declared in the new 'hsSyn/HsExtension.hs' module. To gain a better understanding of the extension mechanism, it has been applied to `HsLit` only, also replacing the `SourceText` fields in them with extension types. To preserve extension generality, a type class is introduced to capture the `SourceText` interface, which must be honoured by all of the extension points which originally had a `SourceText`. The class is defined as class HasSourceText a where -- Provide setters to mimic existing constructors noSourceText :: a sourceText :: String -> a setSourceText :: SourceText -> a getSourceText :: a -> SourceText And the constraint is captured in `SourceTextX`, which is a constraint type listing all the extension points that make use of the class. Updating Haddock submodule to match. Test Plan: ./validate Reviewers: simonpj, shayan-najd, goldfire, austin, bgamari Subscribers: rwbarton, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D3609
* Revert "Treat banged bindings as FunBinds"Ben Gamari2017-05-121-2/+2
| | | | | | | | This partially reverts commit 372995364c52eef15066132d7d1ea8b6760034e6 as it doesn't actually fix #13594. Namely it does not revert the mkPrefixFunRhs refactoring since this is rather independent from the functional changes. Going to try again with a whole working patch
* Fix collect_lpat's treatment of HsSplicedPatsRyan Scott2017-05-111-0/+3
| | | | | | | | | | | | | | | | | | | `collect_lpat` was missing a case for `HsSplicedPat`, which caused incorrect renaming of TH-spliced pattern variables. Fixes #13473. Test Plan: make test TEST=T13473 Reviewers: facundominguez, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13473 Differential Revision: https://phabricator.haskell.org/D3572
* Treat banged bindings as FunBindsBen Gamari2017-05-081-2/+6
| | | | | | | | | | | | | | | | This reworks the HsSyn representation to make banged variable patterns (e.g. !x = e) be represented as FunBinds instead of PatBinds, adding a flag to FunRhs to record the bang. Fixes #13594. Reviewers: austin, goldfire, alanz, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D3525
* Make XNegativeLiterals treat -0.0 as negative 0Nolan2017-05-081-5/+5
| | | | | | | | | | | | Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, mpickering GHC Trac Issues: #13211 Differential Revision: https://phabricator.haskell.org/D3543
* Fix #13233 by checking for lev-poly primopsRichard Eisenberg2017-05-021-2/+5
| | | | | | | | | | | | | | | The implementation plan is all in Note [Detecting forced eta expansion] in DsExpr. Test Plan: ./validate, codeGen/should_fail/T13233 Reviewers: simonpj, austin, bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13233 Differential Revision: https://phabricator.haskell.org/D3490
* Explicitly capture whether a splice has a dollar prefixAlan Zimmerman2017-02-271-4/+4
| | | | | | | | | | | | | A top-level splice can be written $splice or splice For accurate pretty-printing, and for ghc-exactprint, capture in the hsSyn AST which variant was parsed.
* TH-spliced class instances are pretty-printed incorrectly post-#3384Alan Zimmerman2017-02-101-1/+1
| | | | | | | | | | | | | | | | Summary: The HsSyn prettyprinter tests patch 499e43824bda967546ebf95ee33ec1f84a114a7c broke the pretty-printing of Template Haskell-spliced class instances. Test Plan: ./validate Reviewers: RyanGlScott, austin, goldfire, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3043
* Update levity polymorphismRichard Eisenberg2017-01-191-1/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit implements the proposal in https://github.com/ghc-proposals/ghc-proposals/pull/29 and https://github.com/ghc-proposals/ghc-proposals/pull/35. Here are some of the pieces of that proposal: * Some of RuntimeRep's constructors have been shortened. * TupleRep and SumRep are now parameterized over a list of RuntimeReps. * This means that two types with the same kind surely have the same representation. Previously, all unboxed tuples had the same kind, and thus the fact above was false. * RepType.typePrimRep and friends now return a *list* of PrimReps. These functions can now work successfully on unboxed tuples. This change is necessary because we allow abstraction over unboxed tuple types and so cannot always handle unboxed tuples specially as we did before. * We sometimes have to create an Id from a PrimRep. I thus split PtrRep * into LiftedRep and UnliftedRep, so that the created Ids have the right strictness. * The RepType.RepType type was removed, as it didn't seem to help with * much. * The RepType.repType function is also removed, in favor of typePrimRep. * I have waffled a good deal on whether or not to keep VoidRep in TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not* represented in RuntimeRep, and typePrimRep will never return a list including VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can imagine another design choice where we have a PrimRepV type that is PrimRep with an extra constructor. That seemed to be a heavier design, though, and I'm not sure what the benefit would be. * The last, unused vestiges of # (unliftedTypeKind) have been removed. * There were several pretty-printing bugs that this change exposed; * these are fixed. * We previously checked for levity polymorphism in the types of binders. * But we also must exclude levity polymorphism in function arguments. This is hard to check for, requiring a good deal of care in the desugarer. See Note [Levity polymorphism checking] in DsMonad. * In order to efficiently check for levity polymorphism in functions, it * was necessary to add a new bit of IdInfo. See Note [Levity info] in IdInfo. * It is now safe for unlifted types to be unsaturated in Core. Core Lint * is updated accordingly. * We can only know strictness after zonking, so several checks around * strictness in the type-checker (checkStrictBinds, the check for unlifted variables under a ~ pattern) have been moved to the desugarer. * Along the way, I improved the treatment of unlifted vs. banged * bindings. See Note [Strict binds checks] in DsBinds and #13075. * Now that we print type-checked source, we must be careful to print * ConLikes correctly. This is facilitated by a new HsConLikeOut constructor to HsExpr. Particularly troublesome are unlifted pattern synonyms that get an extra void# argument. * Includes a submodule update for haddock, getting rid of #. * New testcases: typecheck/should_fail/StrictBinds typecheck/should_fail/T12973 typecheck/should_run/StrictPats typecheck/should_run/T12809 typecheck/should_fail/T13105 patsyn/should_fail/UnliftedPSBind typecheck/should_fail/LevPolyBounded typecheck/should_compile/T12987 typecheck/should_compile/T11736 * Fixed tickets: #12809 #12973 #11736 #13075 #12987 * This also adds a test case for #13105. This test case is * "compile_fail" and succeeds, because I want the testsuite to monitor the error message. When #13105 is fixed, the test case will compile cleanly.
* Add HsSyn prettyprinter testsAlan Zimmerman2016-12-071-18/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add prettyprinter tests, which take a file, parse it, pretty print it, re-parse the pretty printed version and then compare the original and new ASTs (ignoring locations) Updates haddock submodule to match the AST changes. There are three issues outstanding 1. Extra parens around a context are not reproduced. This will require an AST change and will be done in a separate patch. 2. Currently if an `HsTickPragma` is found, this is not pretty-printed, to prevent noise in the output. I am not sure what the desired behaviour in this case is, so have left it as before. Test Ppr047 is marked as expected fail for this. 3. Apart from in a context, the ParsedSource AST keeps all the parens from the original source. Something is happening in the renamer to remove the parens around visible type application, causing T12530 to fail, as the dumped splice decl is after the renamer. This needs to be fixed by keeping the parens, but I do not know where they are being removed. I have amended the test to pass, by removing the parens in the expected output. Test Plan: ./validate Reviewers: goldfire, mpickering, simonpj, bgamari, austin Reviewed By: simonpj, bgamari Subscribers: simonpj, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2752 GHC Trac Issues: #3384
* Fix used-variable calculation (Trac #12548)Simon Peyton Jones2016-12-051-1/+7
| | | | | | | | | The used-variable calculation for pattern synonyms is a little tricky, for reasons described in RnBinds Note [Pattern synonym builders don't yield dependencies] It was right semantically, but the "unused-variable warning" was wrong, which led to Trac #12548.
* Typos in commentsGabor Greif2016-10-171-1/+1
|
* Remove dead code “mkHsConApp”Joachim Breitner2016-10-061-8/+1
| | | | Differential Revision: https://phabricator.haskell.org/D2574
* Fix impredicativity (again)Simon Peyton Jones2016-09-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes Trac #12616. Dignosis. In TcUnify.tc_sub_type_ds we were going to some trouble to support co- and contra-variance even for impredicative types. With -XImpredicativeTYpes, this allowed a unification variable to be unified with a polytype (probably wrongly) and that caused later trouble in the constraint solver, where -XImpredicativeTypes was /not/ on. In effect, -XImpredicativeTypes can't be switched on locally. Why did we want ImpredicativeTypes locally? Because the program generated by GND for a higher-rank method involved impredicative instantation of 'coerce': op = coerce op -- where op has a higher rank type See Note [Newtype-deriving instances] in TcGenDeriv. Cure. 1. It is ghastly to rely on ImpredicativeTypes (a 100% flaky feature) to instantiate coerce polymorphically. Happily we now have Visible Type Application, so I've used that instead which should be solid and reliable. 2. I deleted the code in tc_sub_type_ds that allows the constraint solver to "look through" a unification variable to find a polytype. That used to be essential in the days of ReturnTv, but it's utterly unreliable and should be consigned to the dustbin of history. (We have ExpType now for the essential uses.) Tests involving ImpredicativeTypes are affected, but I'm not worried about them... it's advertised as a feature you can't rely on, and I want to reform it outright.
* Remove uses of mkMatchGroupNameMatthew Pickering2016-09-111-6/+2
| | | | You can now just use `mkMatchGroup`.
* Generalise type of mkMatchGroup to unify with mkMatchGroupNameMatthew Pickering2016-09-111-6/+4
|
* Fix scoping of type variables in instancesSimon Peyton Jones2016-08-261-1/+28
| | | | | | | | | | | | | | This fixes Trac #12531: class Foo x where foo :: forall a . x a -> x a default foo :: forall b . x b -> x b foo x = go where go :: x b go = undefined We want 'b' to scope over the code for 'foo', but we were using 'a' instead.
* Implement unboxed sum primitive typeÖmer Sinan Ağacan2016-07-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements primitive unboxed sum types, as described in https://ghc.haskell.org/trac/ghc/wiki/UnpackedSumTypes. Main changes are: - Add new syntax for unboxed sums types, terms and patterns. Hidden behind `-XUnboxedSums`. - Add unlifted unboxed sum type constructors and data constructors, extend type and pattern checkers and desugarer. - Add new RuntimeRep for unboxed sums. - Extend unarise pass to translate unboxed sums to unboxed tuples right before code generation. - Add `StgRubbishArg` to `StgArg`, and a new type `CmmArg` for better code generation when sum values are involved. - Add user manual section for unboxed sums. Some other changes: - Generalize `UbxTupleRep` to `MultiRep` and `UbxTupAlt` to `MultiValAlt` to be able to use those with both sums and tuples. - Don't use `tyConPrimRep` in `isVoidTy`: `tyConPrimRep` is really wrong, given an `Any` `TyCon`, there's no way to tell what its kind is, but `kindPrimRep` and in turn `tyConPrimRep` returns `PtrRep`. - Fix some bugs on the way: #12375. Not included in this patch: - Update Haddock for new the new unboxed sum syntax. - `TemplateHaskell` support is left as future work. For reviewers: - Front-end code is mostly trivial and adapted from unboxed tuple code for type checking, pattern checking, renaming, desugaring etc. - Main translation routines are in `RepType` and `UnariseStg`. Documentation in `UnariseStg` should be enough for understanding what's going on. Credits: - Johan Tibell wrote the initial front-end and interface file extensions. - Simon Peyton Jones reviewed this patch many times, wrote some code, and helped with debugging. Reviewers: bgamari, alanz, goldfire, RyanGlScott, simonpj, austin, simonmar, hvr, erikd Reviewed By: simonpj Subscribers: Iceland_jack, ggreif, ezyang, RyanGlScott, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2259
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | With TypeInType Richard combined ForAllTy and FunTy, but that was often awkward, and yielded little benefit becuase in practice the two were always treated separately. This patch re-introduces FunTy. Specfically * New type data TyVarBinder = TvBndr TyVar VisibilityFlag This /always/ has a TyVar it. In many places that's just what what we want, so there are /lots/ of TyBinder -> TyVarBinder changes * TyBinder still exists: data TyBinder = Named TyVarBinder | Anon Type * data Type = ForAllTy TyVarBinder Type | FunTy Type Type | .... There are a LOT of knock-on changes, but they are all routine. The Haddock submodule needs to be updated too
* Improve typechecking of let-bindingsSimon Peyton Jones2016-06-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This major commit was initially triggered by #11339, but it spiraled into a major review of the way in which type signatures for bindings are handled, especially partial type signatures. On the way I fixed a number of other bugs, namely #12069 #12033 #11700 #11339 #11670 The main change is that I completely reorganised the way in which type signatures in bindings are handled. The new story is in TcSigs Note [Overview of type signatures]. Some specific: * Changes in the data types for signatures in TcRnTypes: TcIdSigInfo and new TcIdSigInst * New module TcSigs deals with typechecking type signatures and pragmas. It contains code mostly moved from TcBinds, which is already too big * HsTypes: I swapped the nesting of HsWildCardBndrs and HsImplicitBndsrs, so that the wildcards are on the oustide not the insidde in a LHsSigWcType. This is just a matter of convenient, nothing deep. There are a host of other changes as knock-on effects, and it all took FAR longer than I anticipated :-). But it is a significant improvement, I think. Lots of error messages changed slightly, some just variants but some modest improvements. New tests * typecheck/should_compile * SigTyVars: a scoped-tyvar test * ExPat, ExPatFail: existential pattern bindings * T12069 * T11700 * T11339 * partial-sigs/should_compile * T12033 * T11339a * T11670 One thing to check: * Small change to output from ghc-api/landmines. Need to check with Alan Zimmerman
* Merge MatchFixity and HsMatchContextAlan Zimmerman2016-06-061-15/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: MatchFixity was introduced to facilitate use of API Annotations. HsMatchContext does the same thing with more detail, but is chased through all over the place to provide context when processing a Match. Since we already have MatchFixity in the Match, it may as well provide the full context. updates submodule haddock Test Plan: ./validate Reviewers: austin, goldfire, bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2271 GHC Trac Issues: #12105 (cherry picked from commit 306ecad591951521ac3f5888ca8be85bf749d271)
* Fix deriving Ord when RebindableSyntax is enabledAndrew Farmer2016-05-211-1/+6
| | | | | | | | | | | | | | | | | | | | | | | Deriving clauses (Ord especially) generated if-expressions with nlHsIf which were subject to RebindableSyntax. This changes nlHsIf to generate concrete if-expressions. There was also an error about calling tagToEnum# at a polymorphic type, which is not allowed. Fixing nlHsIf didn't fix this for some reason, so I generated a type ascription around the call to tagToEnum#. Not sure why the typechecker could not figure this out. Test Plan: Added a test, ran validate. Reviewers: simonpj, simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2247 GHC Trac Issues: #12080
* Add TH support for pattern synonyms (fixes #8761)Dominik Bollmann2016-05-121-22/+16
| | | | | | | | | | | | | | | | | | This commit adds Template Haskell support for pattern synonyms as requested by trac ticket #8761. Test Plan: ./validate Reviewers: thomie, jstolarek, osa1, RyanGlScott, mpickering, austin, goldfire, bgamari Reviewed By: goldfire, bgamari Subscribers: rdragon Differential Revision: https://phabricator.haskell.org/D1940 GHC Trac Issues: #8761
* SCC analysis for instances as well as types/classesSimon Peyton Jones2016-04-201-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This big patch is in pursuit of Trac #11348. It is largely the work of Alex Veith (thank you!), with some follow-up simplification and refactoring from Simon PJ. The main payload is described in RnSource Note [Dependency analysis of type, class, and instance decls] which is pretty detailed. * There is a new data type HsDecls.TyClGroup, for a strongly connected component of type/class/instance/role decls. The hs_instds field of HsGroup disappears, in consequence This forces some knock-on changes, including a minor haddock submodule update Smaller, weakly-related things * I found that both the renamer and typechecker were building an identical env for RoleAnnots, so I put common code for RoleAnnotEnv in RnEnv. * I found that tcInstDecls1 had very clumsy error handling, so I put it together into TcInstDcls.doClsInstErrorChecks
* Refactor visible type application.Richard Eisenberg2016-03-141-18/+8
| | | | | | | | | | | | | This replaces the old HsType and HsTypeOut constructors with HsAppType and HsAppTypeOut, leading to some simplification. (This refactoring addresses #11329.) This also fixes #11456, which stumbled over HsType (which is not an expression). test case: ghci/scripts/T11456 [skip ci]
* Allow foralls in instance declsSimon Peyton Jones2016-02-081-65/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch finally makes it possible to have explicit foralls in an instance decl instance forall (a :: *). Eq a => Eq [a] where ... This is useful to allow kind signatures or indeed explicicit kind for-alls; see Trac #11519 I thought it would be really easy, because an instance declaration already contains an actual HsSigType, so all the syntactic baggage is there. But in fact it turned out that instance declarations were kind-checked a little differently, because the body kind of the forall is 'Constraint' rather than '*'. So I fixed that. There a slight kludge (see Note [Body kind of a HsQualTy], but it's still a significant improvement. I also did the usual other round of refactoring, improved a few error messages, tidied up comments etc. The only significant aspect of all that was * Kill mkNakedSpecSigmaTy, mkNakedPhiTy, mkNakedFunTy These function names suggest that they do something complicated, but acutally they do nothing. So I killed them. * Swap the arg order of mkNamedBinder, just so that it is convenient to say 'map (mkNamedBinder Invisible) tvs' * I had to improve isPredTy, to deal with (illegal) types like (Eq a => Eq [a]) => blah See Note [isPeredTy complications] in Type.hs Still to come: user manual documentation for the instance-decl change.
* Refactor the typechecker to use ExpTypes.Richard Eisenberg2016-01-271-27/+53
| | | | | | | | | | | | | | | | | | | | | The idea here is described in [wiki:Typechecker]. Briefly, this refactor keeps solid track of "synthesis" mode vs "checking" in GHC's bidirectional type-checking algorithm. When in synthesis mode, the expected type is just an IORef to write to. In addition, this patch does a significant reworking of RebindableSyntax, allowing much more freedom in the types of the rebindable operators. For example, we can now have `negate :: Int -> Bool` and `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic is in tcSyntaxOp. This addresses tickets #11397, #11452, and #11458. Tests: typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458} th/T11452
* Fix #11405.Richard Eisenberg2016-01-151-0/+1
| | | | | | | This adds a new variant of AbsBinds that is used solely for bindings with a type signature. This allows for a simpler desugaring that does not produce the bogus output that tripped up Core Lint in ticket #11405. Should make other desugarings simpler, too.
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-311-5/+0
| | | | | | | | | | | | Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP compatibility CPP-mess for good! Reviewers: austin, goldfire, bgamari Subscribers: goldfire, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1724
* Visible type applicationRichard Eisenberg2015-12-241-4/+22
| | | | | | | | | | | | | This re-working of the typechecker algorithm is based on the paper "Visible type application", by Richard Eisenberg, Stephanie Weirich, and Hamidhasan Ahmed, to be published at ESOP'16. This patch introduces -XTypeApplications, which allows users to say, for example `id @Int`, which has type `Int -> Int`. See the changes to the user manual for details. This patch addresses tickets #10619, #5296, #10589.
* Comments and white spaceSimon Peyton Jones2015-12-231-1/+1
|
* Make HsAppsType contents LocatedAlan Zimmerman2015-12-221-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | An HsAppInfix can carry a qconop/varop preceded by a SIMPLEQUOTE as a Located RdrName. In this case AnnSimpleQuote is attached to the Located HsAppType. | SIMPLEQUOTE qconop {% ams (sLL $1 $> $ HsAppInfix $2) [mj AnnSimpleQuote $1] } | SIMPLEQUOTE varop {% ams (sLL $1 $> $ HsAppInfix $2) [mj AnnSimpleQuote $1] } This patch changes data HsType name ... | HsAppsTy [HsAppType name] to data HsType name ... | HsAppsTy [LHsAppType name] so that the annotation is not discarded when it reaches the ParsedSource
* Add Location to RdrName in FieldOccAlan Zimmerman2015-12-211-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Post #11019, there have been some new instances of RdrName that are not located, in particular ```#!hs data FieldOcc name = FieldOcc { rdrNameFieldOcc :: RdrName , selectorFieldOcc :: PostRn name name } data AmbiguousFieldOcc name = Unambiguous RdrName (PostRn name name) | Ambiguous RdrName (PostTc name name) deriving (Typeable) ``` Add locations to them Updates haddock submodule to match Test Plan: ./validate Reviewers: goldfire, hvr, bgamari, austin Reviewed By: hvr Subscribers: hvr, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1670 GHC Trac Issues: #11258
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-25/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule.
* Refactor ConDeclAlan Zimmerman2015-12-071-4/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The ConDecl type in HsDecls is an uneasy compromise. For the most part, HsSyn directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's API annotations. But ConDecl doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type ```lang=hs data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ‘::’ , con_doc :: Maybe LHsDocString } | ConDeclH98 { con_name :: Located name , con_qvars :: Maybe (LHsQTyVars name) -- User-written forall (if any), and its implicit -- kind variables -- Non-Nothing needs -XExistentialQuantification , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) ``` Note that For GADTs, just keep a type. That's what the user writes. NB:HsType can represent records on the LHS of an arrow: { x:Int,y:Bool} -> T con_qvars and con_cxt are both Maybe because they are both optional (the forall and the context of an existential data type For ConDeclGADT the type variables of the data type do not scope over the con_type; whereas for ConDeclH98 they do scope over con_cxt and con_details. Updates haddock submodule. Test Plan: ./validate Reviewers: simonpj, erikd, hvr, goldfire, austin, bgamari Subscribers: erikd, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1558 GHC Trac Issues: #11028
* Refactor treatment of wildcardsSimon Peyton Jones2015-12-011-50/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch began as a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. There is one compiler performance regression as a result of all this, in perf/compiler/T3064. I still need to look into that. * The principal driving change is described in Note [HsType binders] in HsType. Well worth reading! * Those data type changes drive almost everything else. In particular we now statically know where (a) implicit quantification only (LHsSigType), e.g. in instance declaratios and SPECIALISE signatures (b) implicit quantification and wildcards (LHsSigWcType) can appear, e.g. in function type signatures * As part of this change, HsForAllTy is (a) simplified (no wildcards) and (b) split into HsForAllTy and HsQualTy. The two contructors appear when and only when the correponding user-level construct appears. Again see Note [HsType binders]. HsExplicitFlag disappears altogether. * Other simplifications - ExprWithTySig no longer needs an ExprWithTySigOut variant - TypeSig no longer needs a PostRn name [name] field for wildcards - PatSynSig records a LHsSigType rather than the decomposed pieces - The mysterious 'GenericSig' is now 'ClassOpSig' * Renamed LHsTyVarBndrs to LHsQTyVars * There are some uninteresting knock-on changes in Haddock, because of the HsSyn changes I also did a bunch of loosely-related changes: * We already had type synonyms CoercionN/CoercionR for nominal and representational coercions. I've added similar treatment for TcCoercionN/TcCoercionR mkWpCastN/mkWpCastN All just type synonyms but jolly useful. * I record-ised ForeignImport and ForeignExport * I improved the (poor) fix to Trac #10896, by making TcTyClsDecls.checkValidTyCl recover from errors, but adding a harmless, abstract TyCon to the envt if so. * I did some significant refactoring in RnEnv.lookupSubBndrOcc, for reasons that I have (embarrassingly) now totally forgotten. It had to do with something to do with import and export Updates haddock submodule.
* ApiAnnotations: Make all RdrName occurences LocatedAlan Zimmerman2015-11-231-8/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment the API Annotations can only be used on the ParsedSource, as there are changes made to the RenamedSource that prevent it from being used to round trip source code. It is possible to build a map from every Located Name in the RenamedSource from its location to the Name, which can then be used when resolved names are required when changing the ParsedSource. However, there are instances where the identifier is not located, specifically (GHC.VarPat name) (GHC.HsVar name) (GHC.UserTyVar name) (GHC.HsTyVar name) Replace each of the name types above with (Located name) Updates the haddock submodule. Test Plan: ./validate Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1512 GHC Trac Issues: #11019
* APIAnnotations:add Locations in hsSyn for layoutAlan Zimmerman2015-11-131-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: At the moment ghc-exactprint, which uses the GHC API Annotations to provide a framework for roundtripping Haskell source code with optional AST edits, has to implement a horrible workaround to manage the points where layout needs to be captured. These are MatchGroup HsDo HsCmdDo HsLet LetStmt HsCmdLet GRHSs To provide a more natural representation, the contents subject to layout rules need to be wrapped in a SrcSpan. This commit does this. Trac ticket #10250 Test Plan: ./validate Reviewers: hvr, goldfire, bgamari, austin, mpickering Reviewed By: mpickering Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1370 GHC Trac Issues: #10250
* Remove fun_infix from Funbind, as it is now in MatchAlan Zimmerman2015-11-111-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One of the changes D538 introduced is to add `m_fun_id_infix` to `Match` ```lang=hs data Match id body = Match { m_fun_id_infix :: (Maybe (Located id,Bool)), -- fun_id and fun_infix for functions with multiple equations -- only present for a RdrName. See note [fun_id in Match] m_pats :: [LPat id], -- The patterns m_type :: (Maybe (LHsType id)), -- A type signature for the result of the match -- Nothing after typechecking m_grhss :: (GRHSs id body) } deriving (Typeable) ``` This was done to track the individual locations and fixity of the `fun_id` for each of the defining equations for a function when there are more than one. For example, the function `(&&&)` is defined with some prefix and some infix equations below. ```lang=hs (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys ``` This means that the fun_infix is now superfluous in the `FunBind`. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after. This ticket captures that task, which includes processing these fields through the renamer and beyond. Ticket #9988 introduced these fields into `Match` through renaming, this ticket it to continue through type checking and then remove it from `FunBind` completely. The split happened so that #9988 could land in 7.10 Trac ticket : #10061 Test Plan: ./validate Reviewers: goldfire, austin, simonpj, bgamari Reviewed By: bgamari Subscribers: simonpj, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1285 GHC Trac Issues: #10061
* Generate Typeable info at definition sitesBen Gamari2015-10-301-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second attempt at merging D757. This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T1969: GHC allocates 19% more * T4801: GHC allocates 13% more * T5321FD: GHC allocates 13% more * T9675: GHC allocates 11% more * T783: GHC allocates 11% more * T5642: GHC allocates 10% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Updates haddock submodule Test Plan: Let Harbormaster validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1404 GHC Trac Issues: #9858
View Lorry Controller Status