summaryrefslogtreecommitdiff
path: root/compiler/types
Commit message (Collapse)AuthorAgeFilesLines
* Minor typofix.Edward Z. Yang2016-08-161-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Implement unboxed sum primitive typeÖmer Sinan Ağacan2016-07-214-129/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* InstEnv: Ensure that instance visibility check is lazyBen Gamari2016-07-201-30/+67
| | | | | | | | | | | | | | | | | | | | | Previously instIsVisible had completely broken the laziness of lookupInstEnv' since it would examine is_dfun_name to check the name of the defining module (to know whether it is an interactive module). This resulted in the visibility check drawing in an interface file unnecessarily. This contributed to the unnecessary regression in compiler allocations reported in #12367. Test Plan: Validate, check nofib changes Reviewers: simonpj, ezyang, austin Reviewed By: ezyang Subscribers: thomie, ezyang Differential Revision: https://phabricator.haskell.org/D2411 GHC Trac Issues: #12367
* Fix misspellings of the word "instance" in commentsRyan Scott2016-07-181-1/+1
| | | | [ci skip]
* tidyOccNames: Rename variables fairlyJoachim Breitner2016-07-141-1/+9
| | | | | | | | | | | So that > :t (id,id,id) produces (id,id,id) :: (a3 -> a3, a2 -> a2, a1 -> a1) instead of (id,id,id) :: (a2 -> a2, a1 -> a1, a -> a) Differential Revision: https://phabricator.haskell.org/D2402
* tidyType: Rename variables of nested forall at onceJoachim Breitner2016-07-131-7/+27
| | | | | this refactoring commit prepares for fixing #12382, which can now be implemented soley in tidyTyCoVarBndrs.
* Use UniqDFM for InstEnvBartosz Nitka2016-07-081-9/+24
| | | | | | | Rationale in the comment. Also updates submodule array with test output changes. GHC Trac: #4012
* Add Note [FamInstEnv determinism]Bartosz Nitka2016-07-071-0/+14
| | | | | | I'm just turning previous commit message into a Note GHC Trac: #4012
* Use deterministic maps for FamInstEnvBartosz Nitka2016-07-071-10/+10
| | | | | | | | | | | | | | We turn FamInstEnvs into lists in some places which don't directly affect the ABI. That happens in family consistency checks and when producing output for `:info`. Unfortunately that nondeterminism is nonlocal and it's hard to tell locally what it affects. Furthermore the envs should be relatively small, so it should be free to use deterministic maps here. Testing with nofib and ./validate detected no difference between UniqFM and UniqDFM. GHC Trac: #4012
* Check generic-default method for ambiguitySimon Peyton Jones2016-07-051-9/+1
| | | | | | | | | | Fixes Trac #7497 and #12151. In some earlier upheaval I introduced a bug in the ambiguity check for genreric-default method. This patch fixes it. But in fixing it I realised that the sourc-location of any such error message was bogus, so I fixed that too, which involved a slightly wider change; see the comments with TcMethInfo.
* Kill some varEnvEltsBartosz Nitka2016-07-051-7/+21
| | | | | | | I was able to hide the nondeterminism in some specialized function, which I believe will be useful in other places. GHC Trac: #4012
* Axe RecFlag on TyCons.Edward Z. Yang2016-06-301-20/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit removes the information about whether or not a TyCon is "recursive", as well as the code responsible for calculating this information. The original trigger for this change was complexity regarding how we computed the RecFlag for hs-boot files. The problem is that in order to determine if a TyCon is recursive or not, we need to determine if it was defined in an hs-boot file (if so, we conservatively assume that it is recursive.) It turns that doing this is quite tricky. The "obvious" strategy is to typecheck the hi-boot file (since we are eventually going to need the typechecked types to check if we properly implemented the hi-boot file) and just extract the names of all defined TyCons from the ModDetails, but this actually does not work well if Names from the hi-boot file are being knot-tied via if_rec_types: the "extraction" process will force thunks, which will force the typechecking process earlier than we have actually defined the types locally. Rather than work around all this trickiness (it certainly can be worked around, either by making interface loading MORE lazy, or just reading of the set of defined TyCons directly from the ModIface), we instead opted to excise the source of the problem, the RecFlag. For one, it is not clear if the RecFlag even makes sense, in the presence of higher-orderness: data T f a = MkT (f a) T doesn't look recursive, but if we instantiate f with T, then it very well is! It was all very shaky. So we just don't bother anymore. This has two user-visible implications: 1. is_too_recursive now assumes that all TyCons are recursive and will bail out in a way that is still mysterious to me if there are too many TyCons. 2. checkRecTc, which is used when stripping newtypes to get to representation, also assumes all TyCons are recursive, and will stop running if we hit the limit. The biggest risk for this patch is that we specialize less than we used to; however, the codeGen tests still seem to be passing. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Reviewers: simonpj, austin, bgamari Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2360
* Deal correctly with unused imports for 'coerce'Simon Peyton Jones2016-06-283-37/+50
| | | | | | | | | | | | | | | | | We only do newtype unwrapping for Coercible constraints if the newtype's data constructor is in scope. We were trying to record the fact that the data constructor was thereby 'used', so that an import statement would not be flagged as unnecsssary (by -Wunused-imports). But the code was simply wrong. It was wrong because it assumed that only one level of unwrapping happened, whereas tcTopNormaliseNewTypeTF_maybe actually unwraps multiple layers. So we need to return a /list/ of data constructors that are used. This entailed a bit of refactoring, as usual. Fixes Trac #12067
* Refactor tcInferArgs and add comments.Richard Eisenberg2016-06-252-2/+23
| | | | | | This removes an unnecessary loop looking for invisible binders and tries to clarify what the very closely-related functions tcInferArgs, tc_infer_args, tcInferApps all do.
* s/Invisible/Inferred/g s/Visible/Required/gRichard Eisenberg2016-06-254-70/+70
| | | | | | | | | | | | | This renames VisibilityFlag from > data VisibilityFlag = Visible | Specified | Invisible to > data ArgFlag = Required | Specified | Inferred The old name was quite confusing, because both Specified and Invisible were invisible! The new names are hopefully clearer.
* Remove bogus comment on ForAllTySimon Peyton Jones2016-06-241-2/+0
|
* Comments around invisibilitySimon Peyton Jones2016-06-242-2/+3
| | | | Very minor
* Remove Ord TyConBartosz Nitka2016-06-231-7/+0
| | | | | | | | After 35d1564cea2e: Provide Uniquable version of SCC we can remove this. We want to remove it because when used it can introduce unnecessary nondeterminism. GHC Trac: #4012
* Provide Uniquable version of SCCBartosz Nitka2016-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | We want to remove the `Ord Unique` instance because there's no way to implement it in deterministic way and it's too easy to use by accident. We sometimes compute SCC for datatypes whose Ord instance is implemented in terms of Unique. The Ord constraint on SCC is just an artifact of some internal data structures. We can have an alternative implementation with a data structure that uses Uniquable instead. This does exactly that and I'm pleased that I didn't have to introduce any duplication to do that. Test Plan: ./validate I looked at performance tests and it's a tiny bit better. Reviewers: bgamari, simonmar, ezyang, austin, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2359 GHC Trac Issues: #4012
* More typos in comments [skip ci]Gabor Greif2016-06-222-2/+2
|
* Major patch to introduce TyConBinderSimon Peyton Jones2016-06-157-332/+327
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, following the TypeInType innovations, each TyCon had two lists: - tyConBinders :: [TyBinder] - tyConTyVars :: [TyVar] They were in 1-1 correspondence and contained overlapping information. More broadly, there were many places where we had to pass around this pair of lists, instead of a single list. This commit tidies all that up, by having just one list of binders in a TyCon: - tyConBinders :: [TyConBinder] The new data types look like this: Var.hs: data TyVarBndr tyvar vis = TvBndr tyvar vis data VisibilityFlag = Visible | Specified | Invisible type TyVarBinder = TyVarBndr TyVar VisibilityFlag TyCon.hs: type TyConBinder = TyVarBndr TyVar TyConBndrVis data TyConBndrVis = NamedTCB VisibilityFlag | AnonTCB TyCoRep.hs: data TyBinder = Named TyVarBinder | Anon Type Note that Var.TyVarBdr has moved from TyCoRep and has been made polymorphic in the tyvar and visiblity fields: type TyVarBinder = TyVarBndr TyVar VisibilityFlag -- Used in ForAllTy type TyConBinder = TyVarBndr TyVar TyConBndrVis -- Used in TyCon type IfaceForAllBndr = TyVarBndr IfaceTvBndr VisibilityFlag type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis -- Ditto, in interface files There are a zillion knock-on changes, but everything arises from these types. It was a bit fiddly to get the module loops to work out right! Some smaller points ~~~~~~~~~~~~~~~~~~~ * Nice new functions TysPrim.mkTemplateKiTyVars TysPrim.mkTemplateTyConBinders which help you make the tyvar binders for dependently-typed TyCons. See comments with their definition. * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code was making an assumption about the order of the kind variables in the kind of GHC.Generics.(:.:). I fixed this; see TcGenGenerics.mkComp.
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-159-405/+431
| | | | | | | | | | | | | | | | | | | | | | 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
* Rename cmpType to nonDetCmpTypeBartosz Nitka2016-06-141-27/+35
| | | | | | | This makes it obvious that it's nondeterministic and hopefully will prevent someone from using it accidentally. GHC Trac: #4012
* Beef up isPredTySimon Peyton Jones2016-06-131-7/+22
| | | | | | | | | | | | isPredTy can be called on ill-kinded types, especially (of course) if there is a kind error. We don't wnat it to crash, but it was, in piResultTy. This patch introduces piResultTy_maybe, and uses it in isPredTy. Ugh. I dislike this code. It's mainly used to know when we should print types with '=>', and we should probably have a better way to signal that.
* Fix the in-scope set for extendTvSubstWithCloneSimon Peyton Jones2016-06-131-2/+6
| | | | | | We'd forgotten the variables free in the kind. Ditto extendCvSubstWithClone
* Comments onlySimon Peyton Jones2016-06-101-23/+1
| | | | ...about unarisation and unboxed tuples
* Comments onlySimon Peyton Jones2016-06-101-1/+1
|
* Remove Ord ClassBartosz Nitka2016-06-091-7/+0
| | | | | | It was implemented in terms of Unique which is nondeterministic GHC Trac: #4012
* Remove Ord (CoAxiom br)Bartosz Nitka2016-06-091-9/+2
| | | | | | | It was implemented in terms of Uniques, but fortunately it's unused so we can remove it. GHC Trac: #4012
* Implement Eq TyCon directlyBartosz Nitka2016-06-091-2/+2
| | | | | | | | Eq TyCon is defined in terms of Ord TyCon, but we want to remove Ord TyCon, because it's implemented in terms of unique comparison, which is nondeterministic. GHC Trac: #4012
* Make FieldLabelEnv a deterministic setBartosz Nitka2016-06-031-5/+5
| | | | | | | | | | | | | | | | | | This lets us kill fsEnvElts function which is nondeterministic. We also get better guarantees than just comments. We don't do lookups, but I believe a set is needed for deduplication. Test Plan: ./validate Reviewers: bgamari, mpickering, austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2297 GHC Trac Issues: #4012
* Localize orphan-related nondeterminismBartosz Nitka2016-06-021-1/+1
| | | | | | | | | | | | | | | chooseOrphanAnchor now takes a NameSet, relieving the callers from the burden of converting it to a list Test Plan: ./validate Reviewers: bgamari, ezyang, austin, simonmar, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2294 GHC Trac Issues: #4012
* More fixes for unboxed tuplesSimon Peyton Jones2016-05-271-5/+5
| | | | | | | | | | | | | | | | | | This is a continuation of commit e9e61f18a548b70693f4ccd245bc56335c94b498 Date: Thu May 26 15:24:53 2016 +0100 Reduce special-casing for nullary unboxed tuple which related to Trac #12115. But typecheck/should_run/tcrun051 revealed that my patch was incomplete. This fixes it, by removing another special case in Type.repType. I had also missed a case in UnariseStg.unariseIdBinder. I took the opportunity to add explanatory notes Note [Unarisation] Note [Unarisation and nullary tuples] in UnariseStg
* Reduce special-casing for nullary unboxed tupleSimon Peyton Jones2016-05-262-123/+138
| | | | | | | | | | | | | | | When we built the kind of a nullary unboxed tuple, we said, in TysWiredIn.mk_tuple: res_rep | arity == 0 = voidRepDataConTy -- See Note [Nullary unboxed tuple] in Type | otherwise = unboxedTupleRepDataConTy But this is bogus. The Note deals with what the 'unarise' transformation does, and up to that point it's simpler and more uniform to treat nullary unboxed tuples the same as all the others. Nicer now. And it fixes the Lint error in Trac #12115
* Remove 'deriving Typeable' statementsRyan Scott2016-05-246-24/+15
| | | | | | | | | | | | | | | | | Summary: Deriving `Typeable` has been a no-op since GHC 7.10, and now that we require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable` statements in GHC. Test Plan: ./validate Reviewers: goldfire, austin, hvr, bgamari Reviewed By: austin, hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2260
* Document some benign nondeterminismBartosz Nitka2016-05-243-5/+19
| | | | | | | | | | | | | | | | | | I've changed the functions to their nonDet equivalents and explained why they're OK there. This allowed me to remove foldNameSet, foldVarEnv, foldVarEnv_Directly, foldVarSet and foldUFM_Directly. Test Plan: ./validate, there should be no change in behavior Reviewers: simonpj, simonmar, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2244 GHC Trac Issues: #4012
* Remove unused Type.splitFunTysNSimon Peyton Jones2016-05-241-10/+1
|
* FunDep printer: Fix unicode arrowÖmer Sinan Ağacan2016-05-201-1/+1
| | | | | | | | | | | | | | | The arrow should be printed in unicode arrow syntax when -fprint-unicode-syntax is used. Reviewers: austin, bgamari, thomie Reviewed By: thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2243 GHC Trac Issues: #11825
* Give lifted primitive types a representationBen Gamari2016-05-191-1/+2
| | | | | | | | | | | | | | | | As of D1774 everything in GHC.Prim has a representation generated for it by TcTypeable (see #11120). Unfortunately I evidently missed propagating this change to lifted primitive types. This patch fixes this (#12082). Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2240 GHC Trac Issues: #12082
* Improve pretty-printing of equalitiesSimon Peyton Jones2016-05-191-57/+50
| | | | | The previous pretty-printer didn't account for partially applied equalities, causing Trac #12041
* Kill varSetElems in tidyFreeTyCoVarsBartosz Nitka2016-05-181-4/+4
| | | | | | | | | | | | | | | | | | | | I haven't observed this to have an effect on nondeterminism, but tidyOccName appears to modify the TidyOccEnv in a way dependent on the order of inputs. It's easy enough to change it to be deterministic to be on the safe side. Test Plan: ./validate Reviewers: simonmar, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2238 GHC Trac Issues: #4012
* Fix deriveTyData's kind unification when two kind variables are unifiedRyanGlScott2016-05-122-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | When `deriveTyData` attempts to unify two kind variables (which can happen if both the typeclass and the datatype are poly-kinded), it mistakenly adds an extra mapping to its substitution which causes the unification to fail when applying the substitution. This can be prevented by checking both the domain and the range of the original substitution to see which kind variables shouldn't be put into the domain of the substitution. A more in-depth explanation is included in `Note [Unification of two kind variables in deriving]`. Fixes #11837. Test Plan: ./validate Reviewers: simonpj, hvr, goldfire, niteria, austin, bgamari Reviewed By: bgamari Subscribers: niteria, thomie Differential Revision: https://phabricator.haskell.org/D2117 GHC Trac Issues: #11837
* Document why closeOverKind is OK for determinismBartosz Nitka2016-05-111-1/+3
| | | | | | | | | | | | | | | | | There's no point in converting the existing call sites to use deterministic closeOverKinds if they never linearize the set. Test Plan: it compiles, this is basically just documentation Reviewers: simonpj, goldfire, simonmar, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2191 GHC Trac Issues: #4012
* Make simplifyInstanceContexts deterministicBartosz Nitka2016-05-101-2/+14
| | | | | | | | | | | | | | | | | | | simplifyInstanceContexts used cmpType which is nondeterministic for canonicalising typeclass constraints in derived instances. Following changes make it deterministic as explained by the Note [Deterministic simplifyInstanceContexts]. Test Plan: ./validate Reviewers: simonmar, goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2173 GHC Trac Issues: #4012
* Comment typos: Mkae -> Make, Hsakell -> HaskellRyanGlScott2016-04-301-1/+1
| | | | [ci skip]
* Fix reference to Note in TcCanonicalRyanGlScott2016-04-301-2/+2
| | | | | | | Previously, it was referring to Note [Decomposing equalities], but the name of it is actually Note [Decomposing equality]. [ci skip]
* Remove the incredibly hairy splitTelescopeTvs.Richard Eisenberg2016-04-291-7/+56
| | | | | | | | | This patch removes splitTelescopeTvs by adding information about scoped type variables to TcTyCon. Vast simplification! This also fixes #11821 by bringing only unzonked vars into scope. Test case: polykinds/T11821
* Add uniqSetAny and uniqSetAll and use themBartosz Nitka2016-04-281-2/+2
| | | | | | | | | | | | | | | | | | There are couple of places where we do `foldUniqSet` just to compute `any` or `all`. `foldUniqSet` is non-deterministic in the general case and `any` and `all` also read nicer. Test Plan: ./validate Reviewers: simonmar, goldfire, simonpj, bgamari, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2156 GHC Trac Issues: #4012
* Kill varSetElems in markNominalBartosz Nitka2016-04-261-1/+1
| | | | | | | | | | | | | | | | | varSetElems introduces unnecessary nondeterminism and it was straighforward to just get a deterministic list. Test Plan: ./validate Reviewers: austin, goldfire, bgamari, simonmar, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2145 GHC Trac Issues: #4012
* Kill varSetElemsWellScoped in quantifyTyVarsBartosz Nitka2016-04-262-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | varSetElemsWellScoped introduces unnecessary non-determinism in inferred type signatures. Removing this instance required changing the representation of TcDepVars to use deterministic sets. This is the last occurence of varSetElemsWellScoped, allowing me to finally remove it. Test Plan: ./validate I will update the expected outputs when commiting, some reordering of type variables in types is expected. Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2135 GHC Trac Issues: #4012
View Lorry Controller Status