summaryrefslogtreecommitdiff
path: root/compiler/utils
Commit message (Collapse)AuthorAgeFilesLines
* Address #11471 by putting RuntimeRep in kinds.wip/runtime-repRichard Eisenberg2016-02-241-0/+16
| | | | | | | | | | | | | | | | | | | | | See Note [TYPE] in TysPrim. There are still some outstanding pieces in #11471 though, so this doesn't actually nail the bug. This commit also contains a few performance improvements: * Short-cut equality checking of nullary type syns * Compare types before kinds in eqType * INLINE coreViewOneStarKind * Store tycon binders separately from kinds. This resulted in a ~10% performance improvement in compiling the Cabal package. No change in functionality other than performance. (This affects the interface file format, though.) This commit updates the haddock submodule.
* Remove superfluous code when deriving Foldable/TraversableRyanGlScott2016-02-171-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, `-XDeriveFoldable` and `-XDeriveTraversable` generate unnecessary `mempty` and `pure` expressions when it traverses of an argument of a constructor whose type does not mention the last type parameter. Not only is this inefficient, but it prevents `Traversable` from being derivable for datatypes with unlifted arguments (see Trac #11174). The solution to this problem is to adopt a slight change to the algorithms for `-XDeriveFoldable` and `-XDeriveTraversable`, which is described in [this wiki page](https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DeriveFu nctor#Proposal:alternativestrategyforderivingFoldableandTraversable). The wiki page also describes why we don't apply the same changes to the algorithm for `-XDeriveFunctor`. This is techincally a breaking change for users of `-XDeriveFoldable` and `-XDeriveTraversable`, since if someone was using a law-breaking `Monoid` instance with a derived `Foldable` instance (i.e., one where `x <> mempty` does not equal `x`) or a law-breaking `Applicative` instance with a derived `Traversable` instance, then the new generated code could result in different behavior. I suspect the number of scenarios like this is very small, and the onus really should be on those users to fix up their `Monoid`/`Applicative` instances. Fixes #11174. Test Plan: ./validate Reviewers: hvr, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1908 GHC Trac Issues: #11174
* Print * has Unicode star with -fprint-unicode-syntaxBen Gamari2016-02-091-0/+1
| | | | | | | | Reviewers: austin, thomie Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1893
* Remote GHCi: parallelise BCO serializationSimon Marlow2016-02-021-0/+8
| | | | | | | | | | | | | | | | | | | Summary: Serialization of BCOs is slow, but we can parallelise it when using ghci -j<n>. It parallelises nicely, saving multiple seconds off the link time in a large example I have. Test Plan: * validate * `ghci -fexternal-interpreter` in `nofib/real/anna` Reviewers: niteria, bgamari, ezyang, austin, hvr, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1877 GHC Trac Issues: #11100
* Add some Outputable instancesOleg Grenrus2016-02-011-0/+4
| | | | | | | | | | Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1865
* Refactor the typechecker to use ExpTypes.Richard Eisenberg2016-01-271-1/+6
| | | | | | | | | | | | | | | | | | | | | 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
* Check InScopeSet in substTy and provide substTyUncheckedBartosz Nitka2016-01-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds sanity checks to `substTy` that implement: > when calling substTy subst ty it should be the case that the in-scope > set in the substitution is a superset of > * The free vars of the range of the substitution > * The free vars of ty minus the domain of the substitution and replaces violators with unchecked version. The violators were found by running the GHC test suite. This ensures that I can work on this incrementally and that what I fix won't be undone by some other change. It also includes a couple of fixes that I've already done. Test Plan: ./validate Reviewers: simonmar, goldfire, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1792 GHC Trac Issues: #11371
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-183-50/+48
| | | | | | | | | | | | | | | | | | | | Summary: In the past the canonical way for constructing an SDoc string literal was the composition `ptext . sLit`. But for some time now we have function `text` that does the same. Plus it has some rules that optimize its runtime behaviour. This patch takes all uses of `ptext . sLit` in the compiler and replaces them with calls to `text`. The main benefits of this patch are clener (shorter) code and less dependencies between module, because many modules now do not need to import `FastString`. I don't expect any performance benefits - we mostly use SDocs to report errors and it seems there is little to be gained here. Test Plan: ./validate Reviewers: bgamari, austin, goldfire, hvr, alanz Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1784
* Work SourceText in for all integer literalsAlan Zimmerman2016-01-161-8/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Certain syntactic elements have integers in them, such as fixity specifications, SPECIALISE pragmas and so on. The lexer will accept mult-radix literals, with arbitrary leading zeros in these. Bring in a SourceText field to each affected AST element to capture the original literal text for use with API Annotations. Affected hsSyn elements are ``` -- See note [Pragma source text] data Activation = NeverActive | AlwaysActive | ActiveBefore SourceText PhaseNum -- Active only *strictly before* this phase | ActiveAfter SourceText PhaseNum -- Active in this phase and later deriving( Eq, Data, Typeable ) -- Eq used in comparing rules in HsDecls data Fixity = Fixity SourceText Int FixityDirection -- Note [Pragma source text] deriving (Data, Typeable) ``` and ``` | HsTickPragma -- A pragma introduced tick SourceText -- Note [Pragma source text] in BasicTypes (StringLiteral,(Int,Int),(Int,Int)) -- external span for this tick ((SourceText,SourceText),(SourceText,SourceText)) -- Source text for the four integers used in the span. -- See note [Pragma source text] in BasicTypes (LHsExpr id) ``` Updates haddock submodule Test Plan: ./validate Reviewers: goldfire, bgamari, austin Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1781 GHC Trac Issues: #11430
* Use implicit CallStacks for ASSERT when availableBartosz Nitka2016-01-131-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This aids with debugging, since all you have to do to get more stack frames is add a constraint `(?callStack :: CallStack) =>`. Old output: ``` ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160107 for x86_64-unknown-linux): ASSERT failed! file compiler/types/TyCoRep.hs line 1800 InScope [] [Xuv :-> n_av5[sk]] [] ``` New output: ``` ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160107 for x86_64-unknown-linux): ASSERT failed! CallStack (from ImplicitParams): assertPprPanic, called at compiler/types/TyCoRep.hs:1800:95 in ghc:TyCoRep InScope [] [Xuv :-> n_av5[sk]] [] ``` Test Plan: harbormaster manual testing Reviewers: austin, gridaphobe, bgamari Reviewed By: gridaphobe, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1751
* Canonicalise `MonadPlus` instancesHerbert Valerio Riedel2016-01-012-11/+9
| | | | | | | This refactoring exploits the fact that since AMP, in most cases, `instance MonadPlus` can be automatically derived from the respective `Alternative` instance. This is because `MonadPlus`'s default method implementations are fully defined in terms of `Alternative(empty, (<>))`.
* Remove some redundant definitions/constraintsHerbert Valerio Riedel2015-12-315-7/+1
| | | | | | Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`, which allows to simplify some definitions to exploit the superclass relationship. This a first refactoring to that end.
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-319-41/+4
| | | | | | | | | | | | 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
* Add sparc64 a known architecture (Ticket #11211)John Paul Adrian Glaubitz2015-12-191-0/+1
| | | | | | | | | | | | Explicitly pass "--no-relax" on ArchSPARC64 (as ArchSPARC does) where gcc's default specs set "-mrelax" which conflicts with "-Wl,-r". Known architecture will also help extending sparc NCG support 64-bit ABI. Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-174-215/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (Apologies for the size of this patch, I couldn't make a smaller one that was validate-clean and also made sense independently) (Some of this code is derived from GHCJS.) This commit adds support for running interpreted code (for GHCi and TemplateHaskell) in a separate process. The functionality is experimental, so for now it is off by default and enabled by the flag -fexternal-interpreter. Reaosns we want this: * compiling Template Haskell code with -prof does not require building the code without -prof first * when GHC itself is profiled, it can interpret unprofiled code, and the same applies to dynamic linking. We would no longer need to force -dynamic-too with TemplateHaskell, and we can load ordinary objects into a dynamically-linked GHCi (and vice versa). * An unprofiled GHCi can load and run profiled code, which means it can use the stack-trace functionality provided by profiling without taking the performance hit on the compiler that profiling would entail. Amongst other things; see https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details. Notes on the implementation are in Note [Remote GHCi] in the new module compiler/ghci/GHCi.hs. It probably needs more documenting, feel free to suggest things I could elaborate on. Things that are not currently implemented for -fexternal-interpreter: * The GHCi debugger * :set prog, :set args in GHCi * `recover` in Template Haskell * Redirecting stdin/stdout for the external process These are all doable, I just wanted to get to a working validate-clean patch first. I also haven't done any benchmarking yet. I expect there to be slight hit to link times for byte code and some penalty due to having to serialize/deserialize TH syntax, but I don't expect it to be a serious problem. There's also lots of low-hanging fruit in the byte code generator/linker that we could exploit to speed things up. Test Plan: * validate * I've run parts of the test suite with EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th. There are a few failures due to the things not currently implemented (see above). Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1562
* Allow recursive (undecidable) superclassesSimon Peyton Jones2015-12-151-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fulfils the request in Trac #11067, #10318, and #10592, by lifting the conservative restrictions on superclass constraints. These restrictions are there (and have been since Haskell was born) to ensure that the transitive superclasses of a class constraint is a finite set. However (a) this restriction is conservative, and can be annoying when there really is no recursion, and (b) sometimes genuinely recursive superclasses are useful (see the tickets). Dimitrios and I worked out that there is actually a relatively simple way to do the job. It’s described in some detail in Note [The superclass story] in TcCanonical Note [Expanding superclasses] in TcType In brief, the idea is to expand superclasses only finitely, but to iterate (using a loop that already existed) if there are more superclasses to explore. Other small things - I improved grouping of error messages a bit in TcErrors - I re-centred the haddock.compiler test, which was at 9.8% above the norm, and which this patch pushed slightly over
* Add IsString Outputable.SDoc instanceHerbert Valerio Riedel2015-12-141-0/+4
| | | | | | | | | | | | | | This allows to conveniently interpret string literals as `text` when `-XOverloadedStrings` is in effect. For what it's worth, `Text.PrettyPrint.Doc` also possesses such an instance. This is a spin-off from D1240 Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1618
* Rework the Implicit CallStack solver to handle local lets.Eric Seidel2015-12-121-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can't just solve CallStack constraints indiscriminately when they occur in the RHS of a let-binder. The top-level given CallStack (if any) will not be in scope, so I've re-worked the CallStack solver as follows: 1. CallStacks are treated like regular IPs unless one of the following two rules apply. 2. In a function call, we push the call-site onto a NEW wanted CallStack, which GHC will solve as a regular IP (either directly from a given, or by quantifying over it in a local let). 3. If, after the constraint solver is done, any wanted CallStacks remain, we default them to the empty CallStack. This rule exists mainly to clean up after rule 2 in a top-level binder with no given CallStack. In rule (2) we have to be careful to emit the new wanted with an IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire again. This is a bit shady but I've updated the Note to explain the trick. Test Plan: validate Reviewers: simonpj, austin, bgamari, hvr Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1422 GHC Trac Issues: #10845
* Add kind equalities to GHC.Richard Eisenberg2015-12-1110-34/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add missing whitespace in toArgs' error msgHerbert Valerio Riedel2015-12-081-2/+2
| | | | Differential Revision: https://phabricator.haskell.org/D1591
* Re-use `transformers`'s `MaybeT` rather than our ownHerbert Valerio Riedel2015-12-071-56/+4
| | | | | | | | | The now removed `MaybeT` type was originally added back in 2008 via bc845b714132a897032502536fea8cd018ce325b Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1583
* Major Overhaul of Pattern Match Checking (Fixes #595)George Karachalias2015-12-032-2/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adresses several problems concerned with exhaustiveness and redundancy checking of pattern matching. The list of improvements includes: * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.). This fixes #4139, #3927, #8970 and other related tickets. * Making the check laziness-aware. Cases that are overlapped but affect evaluation are issued now with "Patterns have inaccessible right hand side". Additionally, "Patterns are overlapped" is now replaced by "Patterns are redundant". * Improved messages for literals. This addresses tickets #5724, #2204, etc. * Improved reasoning concerning cases where simple and overloaded patterns are matched (See #322). * Substantially improved reasoning for pattern guards. Addresses #3078. * OverloadedLists extension does not break exhaustiveness checking anymore (addresses #9951). Note that in general this cannot be handled but if we know that an argument has type '[a]', we treat it as a list since, the instance of 'IsList' gives the identity for both 'fromList' and 'toList'. If the type is not clear or is not the list type, then the check cannot do much still. I am a bit concerned about OverlappingInstances though, since one may override the '[a]' instance with e.g. an '[Int]' instance that is not the identity. * Improved reasoning for nested pattern matching (partial solution). Now we propagate type and (some) term constraints deeper when checking, so we can detect more inconsistencies. For example, this is needed for #4139. I am still not satisfied with several things but I would like to address at least the following before the next release: Term constraints are too many and not printed for non-exhaustive matches (with the exception of literals). This sometimes results in two identical (in appearance) uncovered warnings. Unless we actually show their difference, I would like to have a single warning.
* Implement more deterministic operations and document themBartosz Nitka2015-12-023-12/+176
| | | | | | | | | | | | | | | | I will need them for the future determinism fixes. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari, austin, hvr, simonmar Reviewed By: simonpj, simonmar Subscribers: osa1, thomie Differential Revision: https://phabricator.haskell.org/D1537 GHC Trac Issues: #4012
* Refactor treatment of wildcardsSimon Peyton Jones2015-12-011-14/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Implement warnings for Semigroups as parent of MonoidDavid Luposchainsky2015-11-292-0/+18
| | | | | | | | | | | | | | | | | | | | | This patch is similar to the AMP patch (#8004), which offered two functions: 1. Warn when an instance of a class has been given, but the type does not have a certain superclass instance 2. Warn when top-level definitions conflict with future Prelude names These warnings are issued as part of the new `-Wcompat` warning group. Reviewers: hvr, ekmett, austin, bgamari Reviewed By: hvr, ekmett, bgamari Subscribers: ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1539 GHC Trac Issues: #11139
* Refactor default methods (Trac #11105)Simon Peyton Jones2015-11-251-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does some signficant refactoring to the treatment of default methods in class declarations, and more generally to the type checking of type/class decls. Highlights: * When the class has a generic-default method, such as class C a where op :: a -> a -> Bool default op :: Ord a => a -> a -> a the ClassOpItem records the type of the generic-default, in this case the type (Ord a => a -> a -> a) * I killed off Class.DefMeth in favour of the very-similar BasicTypes.DefMethSpec. However it turned out to be better to use a Maybe, thus Maybe (DefMethSpec Type) with Nothing meaning "no default method". * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing], but I found a way to make it much simpler, accumulating only a [TyCon]. Much less wrapping and unwrapping. * On the way I also fixed Trac #10896 in a better way. Instead of killing off all ambiguity checks whenever there are any type errors (the fix in commit 8e8b9ed), I instead recover in TcTyClsDecls.checkValidTyCl. There was a lot of associated simplification all round
* Rearrange error msgs and add section markers (Trac #11014).Evan Laforge2015-11-241-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This puts the "Relevant bindings" section at the end. It uses a TcErrors.Report Monoid to divide messages by importance and then mappends them together. This is not the most efficient way since there are various intermediate Reports and list appends, but it probably doesn't matter since error messages shouldn't get that large, and are usually prepended. In practice, everything is `important` except `relevantBindings`, which is `supplementary`. ErrMsg's errMsgShortDoc and errMsgExtraInfo were extracted into ErrDoc, which has important, context, and suppelementary fields. Each of those three sections is marked with a bullet character, '•' on unicode terminals and '*' on ascii terminals. Since this breaks tons of tests, I also modified testlib.normalise_errmsg to strip out '•'s. --- Additional notes: To avoid prepending * to an empty doc, I needed to filter empty docs. This seemed less error-prone than trying to modify everyone who produces SDoc to instead produce Maybe SDoc. So I added `Outputable.isEmpty`. Unfortunately it needs a DynFlags, which is kind of bogus, but otherwise I think I'd need another Empty case for SDoc, and then it couldn't be a newtype any more. ErrMsg's errMsgShortString is only used by the Show instance, which is in turn only used by Show HscTypes.SourceError, which is in turn only needed for the Exception instance. So it's probably possible to get rid of errMsgShortString, but that would a be an unrelated cleanup. Fixes #11014. Test Plan: see above Reviewers: austin, simonpj, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: simonpj, nomeata, thomie Differential Revision: https://phabricator.haskell.org/D1427 GHC Trac Issues: #11014
* Create a deterministic version of tyVarsOfTypeBartosz Nitka2015-11-211-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | I've run into situations where I need deterministic `tyVarsOfType` and this implementation achieves that and also brings an algorithmic improvement. Union of two `VarSet`s takes linear time the size of the sets and in the worst case we can have `n` unions of sets of sizes `(n-1, 1), (n-2, 1)...` making it quadratic. One reason why we need deterministic `tyVarsOfType` is in `abstractVars` in `SetLevels`. When we abstract type variables when floating we want them to be abstracted in deterministic order. Test Plan: harbormaster Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1468 GHC Trac Issues: #4012
* Add DVarSet - a deterministic set of VarsBartosz Nitka2015-11-212-8/+230
| | | | | | | | | | | | | | | | | | | | | | | This implements `DVarSet`, a deterministic set of Vars, with an interface very similar to `VarSet` with a couple of functions missing. I will need this in changes that follow, one of them will be about changing the type of the set of Vars that `RuleInfo` holds to make the free variable computation deterministic. Test Plan: ./validate I can add new tests if anyone wants me to. Reviewers: simonpj, simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1487 GHC Trac Issues: #4012
* Make GHC aware of OSAIX and AixLDHerbert Valerio Riedel2015-11-191-0/+2
| | | | | | | | | | | | | | GHC needs to be aware of targetting AIX because AIX requires some special handling for the toolchain (similiar to Solaris) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, erikd Differential Revision: https://phabricator.haskell.org/D1501
* Fix inconsistent pretty-printing of type familiesMichał Sośnicki2015-11-183-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | After the changes, the three functions used to print type families were identical, so they are refactored into one. Original RHSs of data instance declarations are recreated and printed in user error messages. RHSs containing representation TyCons are printed in the Coercion Axioms section in a typechecker dump. Add vbar to the list of SDocs exported by Outputable. Replace all text "|" docs with it. Fixes #10839 Reviewers: goldfire, jstolarek, austin, bgamari Reviewed By: jstolarek Subscribers: jstolarek, thomie Differential Revision: https://phabricator.haskell.org/D1441 GHC Trac Issues: #10839
* MonadFail proposal, phase 1David Luposchainsky2015-11-172-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | This implements phase 1 of the MonadFail proposal (MFP, #10751). - MonadFail warnings are all issued as desired, tunable with two new flags - GHC was *not* made warning-free with `-fwarn-missing-monadfail-warnings` (but it's disabled by default right now) Credits/thanks to - Franz Thoma, whose help was crucial to implementing this - My employer TNG Technology Consulting GmbH for partially funding us for this work Reviewers: goldfire, austin, #core_libraries_committee, hvr, bgamari, fmthoma Reviewed By: hvr, bgamari, fmthoma Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1248 GHC Trac Issues: #10751
* Remove orphan Functor instance of Data.Graph.SCCÖmer Sinan Ağacan2015-11-171-10/+1
| | | | | | | | | | Reviewers: bgamari, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1481
* Fix bootstrapping with GHC 7.10.1Ben Gamari2015-11-141-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Relying on CallStack being in GLASGOW_HASKELL >= 710 breaks bootstrappability with 7.10.1 7.10.2 added the CallStack mechanism, and GHC already relies on this while being built. Unfortunately, it is enabled with "GLASGOW_HASKELL >= 710", which also applies to GHC 7.10.1, which does not have CallStack, and fails building the stage-1 compiler because the symbol is not found. This patch makes the CPP directive more strict, requiring **more than** 7.10 instead of **at least**. Reviewers: jstolarek, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1472 GHC Trac Issues: #11085
* Give helpful advice when a fully qualified name is not in scopeJoachim Breitner2015-11-131-1/+7
| | | | | | | | | | This implements #11071. It needs to thread through a GlobalRdrEnv corresponding to the export list of the module if its exports were not restricted. A refactoring of ImportedModsVal into a proper data type follows. Differential Revision: https://phabricator.haskell.org/D1462
* OPTIONS_GHC compiler flags may contain spaces (#4931)Thomas Miedema2015-11-111-14/+27
| | | | | | | | | | | | | | | | | | | When a .hsc contains `#define FOO "bar baz"`, hsc2hs emits: {-# OPTIONS_GHC -optc-DFOO="bar baz" #-} Make sure GHC can compile this, by tweaking `HeaderInfo.getOptions` a bit. Test Plan: driver/T4931 Reviewers: austin, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1452 GHC Trac Issues: #4931
* Add pprSTrace for debugging with call stacksBartosz Nitka2015-11-081-1/+15
| | | | | | | | | | | | | | | | | I've spent quite a bit of time giving unique labels to my `pprTrace` calls and then trying to intuit where the function is called from. Thanks to the new implicit parameter CallStack functionality I don't have to do that anymore. Test Plan: harbormaster Reviewers: austin, simonmar, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1440
* ApiAnnotations: BooleanFormula is not properly LocatedAlan Zimmerman2015-11-011-27/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment BooleanFormula is defined as data BooleanFormula a = Var a | And [BooleanFormula a] | Or [BooleanFormula a] deriving (Eq, Data, Typeable, Functor, Foldable, Traversable) An API Annotation can only be attached to an item of the form Located a. Replace this with a properly Located version, and attach the appropriate API Annotations to it Updates haddock submodule. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1384 GHC Trac Issues: #11017
* Make type-class dictionary let binds deterministicBartosz Nitka2015-10-301-0/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When generating dictionary let binds in dsTcEvBinds we may end up generating them in arbitrary order according to Unique order. Consider: ``` let $dEq = GHC.Classes.$fEqInt in let $$dNum = GHC.Num.$fNumInt in ... ``` vs ``` let $dNum = GHC.Num.$fNumInt in let $dEq = GHC.Classes.$fEqInt in ... ``` The way this change fixes it is by using `UniqDFM` - a type of deterministic finite maps of things keyed on `Unique`s. This way when you pull out evidence variables corresponding to type-class dictionaries they are in deterministic order. Currently it's the order of insertion and the way it's implemented is by tagging the values with the time of insertion. Test Plan: I've added a new test case to reproduce the issue. ./validate Reviewers: ezyang, simonmar, austin, simonpj, bgamari Reviewed By: simonmar, simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1396 GHC Trac Issues: #4012
* Generate Typeable info at definition sitesBen Gamari2015-10-301-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Generate Typeable info at definition sites"Ben Gamari2015-10-291-7/+4
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-291-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less 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. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757
* Make stronglyConnCompFromEdgedVertices deterministicBartosz Nitka2015-10-221-18/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes it so the result of computing SCC's depends on the order the nodes were passed to it, but not on the order on the user provided key type. The key type is usually `Unique` which is known to be nondeterministic. Test Plan: `text` and `aeson` become deterministic after this ./validate Compare compile time for `text`: ``` $ cabal get text && cd text* && cabal sandbox init && cabal install --dependencies-only && time cabal build real 0m59.459s user 0m57.862s sys 0m1.185s $ cabal clean && time cabal build real 1m0.037s user 0m58.350s sys 0m1.199s $ cabal clean && time cabal build real 0m57.634s user 0m56.118s sys 0m1.202s $ cabal get text && cd text* && cabal sandbox init && cabal install --dependencies-only && time cabal build real 0m59.867s user 0m58.176s sys 0m1.188s $ cabal clean && time cabal build real 1m0.157s user 0m58.622s sys 0m1.177s $ cabal clean && time cabal build real 1m0.950s user 0m59.397s sys 0m1.083s ``` Reviewers: ezyang, simonmar, austin, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1268 GHC Trac Issues: #4012
* Make Monad/Applicative instances MRP-friendlyHerbert Valerio Riedel2015-10-175-17/+29
| | | | | | | | | | | | | | | | | | | | | | | | | This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e. such that the explicit definitions for `return` and `(>>)` match the MRP-style default-implementation, i.e. return = pure and (>>) = (*>) This way, e.g. all `return = pure` definitions can easily be grepped and removed in GHC 8.1; Test Plan: Harbormaster Reviewers: goldfire, alanz, bgamari, quchen, austin Reviewed By: quchen, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1312
* Implement DuplicateRecordFieldsAdam Gundry2015-10-161-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements DuplicateRecordFields, the first part of the OverloadedRecordFields extension, as described at https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields This includes fairly wide-ranging changes in order to allow multiple records within the same module to use the same field names. Note that it does *not* allow record selector functions to be used if they are ambiguous, and it does not have any form of type-based disambiguation for selectors (but it does for updates). Subsequent parts will make overloading selectors possible using orthogonal extensions, as described on the wiki pages. This part touches quite a lot of the codebase, and requires changes to several GHC API datatypes in order to distinguish between field labels (which may be overloaded) and selector function names (which are always unique). The Haddock submodule has been adapted to compile with the GHC API changes, but it will need further work to properly support modules that use the DuplicateRecordFields extension. Test Plan: New tests added in testsuite/tests/overloadedrecflds; these will be extended once the other parts are implemented. Reviewers: goldfire, bgamari, simonpj, austin Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D761
* Rename package key to unit ID, and installed package ID to component ID.Edward Z. Yang2015-10-141-3/+3
| | | | | | Comes with Haddock submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Prevent GHC from silently dying when preprocessor is not foundTamar Christina2015-10-031-15/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows preprocessor code calls `runInteractiveProcess` but does not check if an exception is thrown. `runInteractiveProcess` calls `CreateProcess` which when given a format the system loader does not know about will throw an exception. This is what makes #9399 fail. Ultimately we should not use any `CreateProcess` based calls but instead `ShellExecuteEx` as this would allow us to run applications that the shell knows about instead of just the loader. More details on #365. This patch removes `PhaseFailed` and throws `ProgramError` instead. `PhaseFailed` was largely unneeded since it never gave very useful information aside from the `errorcode` which was almost always `1`. `IOErrors` have also been eliminated and `GhcExceptions` thrown in their place wherever possible. Updates haddock submodule. Test Plan: `./validate` to make sure anything didn't break and `make TESTS="T365"` to test that an error is now properly thrown Reviewers: austin, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1256 GHC Trac Issues: #365
* Skip a possible BOM in utf8 encodingJoachim Breitner2015-09-251-3/+7
| | | | | | | | and not the system locale, which might be something else. This fixes bug #10907. A test is added, but less useful than it could be until task #10909 is done. Differential Revision: D1274
* Make derived names deterministicBartosz Nitka2015-09-211-1/+50
| | | | | | | | | | | | | | | | | | | | | | The names of auxiliary bindings end up in the interface file, and since uniques are nondeterministic, we end up with nondeterministic interface files. This uses the package and module name in the generated name, so I believe it should avoid problems from #7947 and be deterministic as well. The generated names look like this now: `$cLrlbmVwI3gpI8G2E6Hg3mO` and with `-ppr-debug`: `$c$aeson_70dylHtv1FFGeai1IoxcQr$Data.Aeson.Types.Internal$String`. Reviewed By: simonmar, austin, ezyang Differential Revision: https://phabricator.haskell.org/D1133 GHC Trac Issues: #4012
* Remove graphFromVerticesAndAdjacencyBartosz Nitka2015-09-211-19/+1
| | | | | | | | It's not used anywhere. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1266
View Lorry Controller Status