summaryrefslogtreecommitdiff
path: root/compiler/utils/Binary.hs
Commit message (Collapse)AuthorAgeFilesLines
* Typos [ci skip]Gabor Greif2017-05-101-2/+2
|
* Read COMPLETE sets from external packagesBen Gamari2017-03-061-1/+0
| | | | | | | | | | | | | | | | | | | | | | Currently, `COMPLETE` pragmas are not read from external packages at all, which quite limits their usefulness. This extends `ExternalPackageState` to include `COMPLETE` sets from other packages, and plumbs around the appropriate values to make it work the way you'd expect it to. Requires a `binary` submodule update. Fixes #13350. Test Plan: make test TEST=T13350 Reviewers: rwbarton, mpickering, austin, simonpj, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3257
* Revert "Read COMPLETE sets from external packages"Ben Gamari2017-03-031-0/+1
| | | | This reverts commit 0d2f733050ff656b827351108d988e09abc363fc.
* Read COMPLETE sets from external packagesRyan Scott2017-03-021-1/+0
| | | | | | | | | | | | | | | | | | | | Currently, `COMPLETE` pragmas are not read from external packages at all, which quite limits their usefulness. This extends `ExternalPackageState` to include `COMPLETE` sets from other packages, and plumbs around the appropriate values to make it work the way you'd expect it to. Fixes #13350. Test Plan: make test TEST=T13350 Reviewers: rwbarton, mpickering, austin, simonpj, bgamari Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D3257
* Use half as much memory when reading interfacesReid Barton2017-02-231-1/+1
| | | | | | | | | | | | | | | I don't see any reason for the (filesize*2), and experimentally allocations do go down slightly after this change. Test Plan: validate Reviewers: simonmar, austin, bgamari, trofi Reviewed By: bgamari, trofi Subscribers: trofi, thomie Differential Revision: https://phabricator.haskell.org/D3164
* Type-indexed TypeableBen Gamari2017-02-181-4/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal.
* Binary: Correct endian issue when cross-compilingalexbiehl2017-02-111-30/+55
| | | | | | | | | | | | | | Using `WORDS_BIGENDIAN` wasn't such a great idea after all! When cross compiling host and target endianess may differ and `WORDS_BIGENDIAN` refers to host endianess. Reviewers: austin, bgamari, trofi Reviewed By: bgamari, trofi Subscribers: rwbarton, trofi, thomie Differential Revision: https://phabricator.haskell.org/D3122
* Binary: Only allocate un-interned FastStringsalexbiehl2017-02-111-2/+3
| | | | | | | | | | | | Test Plan: Validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3109
* Use proper primitives in Utils.Binaryalexbiehl2017-02-051-93/+96
| | | | | | | | | | | | | | `Word{16,32,64}` are implemented using `getWord8`. This patch introduces `getWord{16,32,64}` and `putWord{16,32,64}`. This is nicer and probably a bit faster. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2908
* Add HsSyn prettyprinter testsAlan Zimmerman2016-12-071-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Kill Type pretty-printerBen Gamari2016-11-131-0/+8
| | | | | | | | | | | | | | | | | | | | | | Here we consolidate the pretty-printing logic for types in IfaceType. We need IfaceType regardless and the printer for Type can be implemented in terms of that for IfaceType. See #11660. Note that this is very much a work-in-progress. Namely I still have yet to ponder how to ease the hs-boot file situation, still need to rip out more dead code, need to move some of the special cases for, e.g., `*` to the IfaceType printer, and need to get it to validate. That being said, it comes close to validating as-is. Test Plan: Validate Reviewers: goldfire, austin Subscribers: goldfire, thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2528 GHC Trac Issues: #11660
* Clean up handling of known-key Names in interface filesBen Gamari2016-10-131-30/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously BinIface had some dedicated logic for handling tuple names in the symbol table. As it turns out, this logic was essentially dead code as it was superceded by the special handling of known-key things. Here we cull the tuple code-path and use the known-key codepath for all tuple-ish things. This had a surprising number of knock-on effects, * constraint tuple datacons had to be made known-key (previously they were not) * IfaceTopBndr was changed from being a synonym of OccName to a synonym of Name (since we now need to be able to deserialize Names directly from interface files) * the change to IfaceTopBndr complicated fingerprinting, since we need to ensure that we don't go looking for the fingerprint of the thing we are currently fingerprinting in the fingerprint environment (see notes in MkIface). Handling this required distinguishing between binding and non-binding Name occurrences in the Binary serializers. * the original name cache logic which previously lived in IfaceEnv has been moved to a new NameCache module * I ripped tuples and sums out of knownKeyNames since they introduce a very large number of entries. During interface file deserialization we use static functions (defined in the new KnownUniques module) to map from a Unique to a known-key Name (the Unique better correspond to a known-key name!) When we need to do an original name cache lookup we rely on the parser implemented in isBuiltInOcc_maybe. * HscMain.allKnownKeyNames was folded into PrelInfo.knownKeyNames. * Lots of comments were sprinkled about describing the new scheme. Updates haddock submodule. Test Plan: Validate Reviewers: niteria, simonpj, austin, hvr Reviewed By: simonpj Subscribers: simonmar, niteria, thomie Differential Revision: https://phabricator.haskell.org/D2467 GHC Trac Issues: #12532, #12415
* Fix #10923 by fingerprinting optimization level.Edward Z. Yang2016-09-021-0/+11
| | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonmar, austin, bgamari, thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D2509 GHC Trac Issues: #10923
* Binary: Use ByteString's copy in getBSBen Gamari2016-07-161-19/+12
| | | | | | | | | | | | | | It's unclear how much of an effect on runtime this will have, but if nothing else the code generation may be a tad better since the system's `memcpy` will be used. Test Plan: Validate Reviewers: simonmar, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2401
* Document putDictionary determinismBartosz Nitka2016-06-061-1/+3
| | | | | | | | | | | | | | Summary: Like explained in the comment it's OK here. Test Plan: ./validate Reviewers: simonmar, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2306 GHC Trac Issues: #4012
* Revert "compiler/iface: compress .hi files"Ben Gamari2016-05-231-18/+19
| | | | | | | | | | | | | | | | | | | | | This appears to cause validation issues on, TEST="T11108 T9071 T11076 T7600 T7672 T8329 T10420 T10322 T8308 T4114a T4114c T10602 T10110 T9204 T2435 T9838 T4114d T10233 T8696 T1735 T5281 T6056 T10134 T9580 T6018 T9762 T8103" With compiler panics of the form, Compile failed (status 256) errors were: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160523 for x86_64-unknown-linux): Binary.readBinMem: decompression failed CallStack (from HasCallStack): error, called at compiler/utils/Binary.hs:192:16 in ghc:Binary Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This reverts commit d9cb7a8a94daa4d20aa042cd053e20b491315633.
* compiler/iface: compress .hi filesAustin Seipp2016-05-211-19/+18
| | | | | | | | | | | | | | | | | | | Compress all interface files generated by the compiler with LZ4. While being only a tiny amount of code, LZ4 is both fast at compression and decompression, and has good compression ratios. Non-scientific size test: size of stage2 compiler .hi files: `find ./compiler/stage2 -type f -iname '*.hi' -exec du -ch {} + | grep total$` Without this patch: 22MB of .hi files for stage2. With this patch: 9.2MB of .hi files for stage2. Signed-off-by: Austin Seipp <austin@well-typed.com> Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1159
* 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
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* 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
* Delete ExtsCompat46 (#8330)Thomas Miedema2015-08-241-14/+7
| | | | | | We require ghc-7.8 to build HEAD (ghc-7.11). Differential Revision: https://phabricator.haskell.org/D1165
* Replace (SourceText,FastString) with StringLiteral data typeAlan Zimmerman2015-08-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Phab:D907 introduced SourceText for a number of data types, by replacing FastString with (SourceText,FastString). Since this has an Outputable instance, no warnings are generated when ppr is called on it, but unexpected output is generated. See Phab:D1096 for an example of this. Replace the (SourceText,FastString) tuples with a new data type, ```lang=hs data StringLiteral = StringLiteral SourceText FastString ``` Update haddock submodule accordingly Test Plan: ./validate Reviewers: hvr, austin, rwbarton, trofi, bgamari Reviewed By: trofi, bgamari Subscribers: thomie, trofi, rwbarton, mpickering Differential Revision: https://phabricator.haskell.org/D1101 GHC Trac Issues: #10692
* Replace .lhs with .hs in compiler commentsYuri de Wit2015-02-091-1/+1
| | | | | | | | | | | | | | Summary: It looks like during .lhs -> .hs switch the comments were not updated. So doing exactly that. Reviewers: austin, jstolarek, hvr, goldfire Reviewed By: austin, jstolarek Subscribers: thomie, goldfire Differential Revision: https://phabricator.haskell.org/D621 GHC Trac Issues: #9986
* API Annotations tweaks.Alan Zimmerman2015-01-161-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: HsTyLit now has SourceText Update documentation of HsSyn to reflect which annotations are attached to which element. Ensure that the parser always keeps HsSCC and HsTickPragma values, to be ignored in the desugar phase if not needed Bringing in SourceText for pragmas Add Location in NPlusKPat Add Location in FunDep Make RecCon payload Located Explicitly add AnnVal to RdrName where it is compound Add Location in IPBind Add Location to name in IEThingAbs Add Maybe (Located id,Bool) to Match to track fun_id,infix This includes converting Match into a record and adding a note about why the fun_id needs to be replicated in the Match. Add Location in KindedTyVar Sort out semi-colons for parsing - import statements - stmts - decls - decls_cls - decls_inst This updates the haddock submodule. Test Plan: ./validate Reviewers: hvr, austin, goldfire, simonpj Reviewed By: simonpj Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D538
* Remove redundant constraints in the compiler itself, found by ↵Simon Peyton Jones2015-01-061-1/+1
| | | | -fwarn-redundant-constraints
* AST changes to prepare for API annotations, for #9628Alan Zimmerman2014-11-211-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: AST changes to prepare for API annotations Add locations to parts of the AST so that API annotations can then be added. The outline of the whole process is captured here https://ghc.haskell.org/trac/ghc/wiki/GhcAstAnnotations This change updates the haddock submodule. Test Plan: sh ./validate Reviewers: austin, simonpj, Mikolaj Reviewed By: simonpj, Mikolaj Subscribers: thomie, goldfire, carter Differential Revision: https://phabricator.haskell.org/D426 GHC Trac Issues: #9628
* Delete all /* ! __GLASGOW_HASKELL__ */ codeThomas Miedema2014-09-231-5/+0
| | | | | | | | | | | | | | | | | Summary: ``` git grep -l '\(#ifdef \|#if defined\)(\?__GLASGOW_HASKELL__)\?' ``` Test Plan: validate Reviewers: rwbarton, hvr, austin Reviewed By: rwbarton, hvr, austin Subscribers: rwbarton, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D218
* Make mkFastStringByteString pure and fix up usesDuncan Coutts2014-08-291-1/+1
| | | | It's morally pure, and we'll need it in a pure context.
* Implement OVERLAPPING and OVERLAPPABLE pragmas (see #9242)Iavor S. Diatchki2014-07-271-4/+8
| | | | | | | | | | | | | | | | | | | | | | This also removes the short-lived NO_OVERLAP pragama, and renames OVERLAP to OVERLAPS. An instance may be annotated with one of 4 pragams, to control its interaction with other overlapping instances: * OVERLAPPABLE: this instance is ignored if a more specific candidate exists * OVERLAPPING: this instance is preferred over more general candidates * OVERLAPS: both OVERLAPPING and OVERLAPPABLE (i.e., the previous GHC behavior). When compiling with -XOverlappingInstances, all instance are OVERLAPS. * INCOHERENT: same as before (see manual for details). When compiling with -XIncoherentInstances, all instances are INCOHERENT.
* Factor-out the `OverlapMode` from `OverlapFlag`.Iavor S. Diatchki2014-06-291-9/+17
| | | | | | | | This seems a bit cleaner conceptually because the overlap mode and running in safety mode are quite orthogonal. More pragmatically, it also makes it possible to use `OverlapMode` to let programmers pick the overlap mode for individual instances.
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-151-1/+1
| | | | | | | | | | | | | | | | | | In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been reorganized, while following the convention, to - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before any `{-# OPTIONS_GHC #-}`-lines. - Moreover, if the list of language extensions fit into a single `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each individual language extension. In both cases, try to keep the enumeration alphabetically ordered. (The latter layout is preferable as it's more diff-friendly) While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
* Avoid trivial cases of NondecreasingIndentationHerbert Valerio Riedel2014-05-151-4/+3
| | | | | | | This cleanup allows the following refactoring commit to avoid adding a few `{-# LANGUAGE NondecreasingIndentation #-}` pragmas. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Restore old names of comparison primopsJan Stolarek2013-09-181-1/+1
| | | | | | | | | | | | In 6579a6c we removed existing comparison primops and introduced new ones returning Int# instead of Bool. This commit (and associated commits in array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and template-haskell) restores old names of primops. This allows us to keep our API cleaner at the price of not having backwards compatibility. This patch also temporalily disables fix for #8317 (optimization of tagToEnum# at Core level). We need to fix #8326 first, otherwise our primops code will be very slow.
* Trailing whitespacesJan Stolarek2013-09-181-3/+3
|
* Binary: eradicate BinIO handlesPatrick Palka2013-08-261-44/+0
| | | | They are not used anywhere in the compiler.
* Binary: Make lazyGet more thread-safePatrick Palka2013-08-261-1/+6
| | | | | | | | | | | | | | | All values read lazily from the same BinHandle share the same mutable offset variable (_off_r). If two such lazy values are simultaneously evaluated, the two threads will step over each other when writing to _off_r. Fortunately, for BinMem handles, making lazyGet thread-safe is simple: just use a fresh off_r variable when deferring the call to getAt. For BinIO handles, a race condition still exists because IO handles contain their own mutable file pointer variable that gets clobbered in a similar way that _off_r would. But GHC doesn't use BinIO handles anywhere so this particular issue could be ignored for now.
* De-orphan a load of Binary instancesIan Lynagh2013-07-271-0/+141
|
* Rename remaining FastBytes usages to ByteStringIan Lynagh2012-12-141-1/+1
|
* Remove the trivial mkFastStringFastBytes wrapperIan Lynagh2012-12-141-1/+1
|
* Use ByteString rather than FastBytes in BinaryIan Lynagh2012-12-141-13/+15
|
* Make FastBytes a synonym for ByteStringIan Lynagh2012-12-131-6/+6
| | | | | | | | | | | A step on the way to getting rid of FastBytes slow nofib Compile times look like: -1 s.d. -2.4% +1 s.d. +3.4% Average +0.4% but looking at the times for the longer-running compilations I think the change is just noise.
* GHC 7.4 is now required for building HEADIan Lynagh2012-07-201-12/+0
|
* Implement FastBytes, and use it for MachStrIan Lynagh2012-07-141-6/+17
| | | | | | | | | | | | | This is a first step on the way to refactoring the FastString type. FastBytes currently has no unique, mainly because there isn't currently a nice way to produce them in Binary. Also, we don't currently do the "Dictionary" thing with FastBytes in Binary. I'm not sure whether this is important. We can change both decisions later, but in the meantime this gets the refactoring underway.
* Remove some disabled codeIan Lynagh2012-05-291-3/+0
|
* Switch to using the time package, rather than old-timeIan Lynagh2012-01-141-0/+18
|
* Fix #437: recompilation check includes flagsDavid Terei2011-11-091-11/+21
|
* Change the way IfExtName is serialized so (most) wired-in names get special ↵Max Bolingbroke2011-09-271-22/+24
| | | | | | | | representation This lets IfaceType be dumber, with fewer special cases, because deserialization for more wired-in names will work. Once we have polymorphic kinds we will be able to replace IfaceTyCon with a simple IfExtName.
View Lorry Controller Status