summaryrefslogtreecommitdiff
path: root/compiler/utils/Binary.hs
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* fix Binary instance for TyCon following Typeable implementationSimon Marlow2011-07-121-0/+12
| | | | changes
* move computeFingerprint from MkIface to BinarySimon Marlow2011-07-121-0/+14
|
* SafeHaskell: Make base GHC.* modules untrustedDavid Terei2011-06-171-1/+1
|
* SafeHaskell: Update to work with safe baseDavid Terei2011-06-171-1/+2
|
* SafeHaskell: Fix recompilation avoidance to take Safe into account.David Terei2011-06-171-0/+9
|
* Remove code that is dead now that we need >= 6.12 to buildIan Lynagh2010-12-151-5/+0
|
* Use explicit Word32/Int32 in place of Int in the on-disk .hi fileSimon Marlow2009-08-211-3/+3
| | | | | For: FastStrings, Names, and Bin values. This makes .hi files smaller on 64-bit platforms, while also making the format a bit more robust.
* RTS tidyup sweep, first phaseSimon Marlow2009-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first phase of this tidyup is focussed on the header files, and in particular making sure we are exposinng publicly exactly what we need to, and no more. - Rts.h now includes everything that the RTS exposes publicly, rather than a random subset of it. - Most of the public header files have moved into subdirectories, and many of them have been renamed. But clients should not need to include any of the other headers directly, just #include the main public headers: Rts.h, HsFFI.h, RtsAPI.h. - All the headers needed for via-C compilation have moved into the stg subdirectory, which is self-contained. Most of the headers for the rest of the RTS APIs have moved into the rts subdirectory. - I left MachDeps.h where it is, because it is so widely used in Haskell code. - I left a deprecated stub for RtsFlags.h in place. The flag structures are now exposed by Rts.h. - Various internal APIs are no longer exposed by public header files. - Various bits of dead code and declarations have been removed - More gcc warnings are turned on, and the RTS code is more warning-clean. - More source files #include "PosixSource.h", and hence only use standard POSIX (1003.1c-1995) interfaces. There is a lot more tidying up still to do, this is just the first pass. I also intend to standardise the names for external RTS APIs (e.g use the rts_ prefix consistently), and declare the internal APIs as hidden for shared libraries.
* Always serialise Int as 64bit values; fixes trac #3041Ian Lynagh2009-07-171-9/+0
| | | | | | This means that, provided the values are small enough, files serialized are portable between architectures. In particular, .haddock files are portable.
* Remove some code that has always been commented outIan Lynagh2009-07-171-4/+0
|
* Trim unused imports detected by new unused-import codesimonpj@microsoft.com2009-07-061-4/+0
|
* Support for -fwarn-unused-do-bind and -fwarn-wrong-do-bind, as per #3263Max Bolingbroke2009-07-011-2/+2
|
* Changes for the new IO library, mainly base-package modules moving aroundSimon Marlow2009-05-291-1/+6
|
* When generating C, don't pretend functions are dataIan Lynagh2009-02-061-0/+11
| | | | | | | | | | | | | | | We used to generated things like: extern StgWordArray (newCAF) __attribute__((aligned (8))); ((void (*)(void *))(W_)&newCAF)((void *)R1.w); (which is to say, pretend that newCAF is some data, then cast it to a function and call it). This goes wrong on at least IA64, where: A function pointer on the ia64 does not point to the first byte of code. Intsead, it points to a structure that describes the function. The first quadword in the structure is the address of the first byte of code so we end up dereferencing function pointers one time too many, and segfaulting.
* Add (a) CoreM monad, (b) new Annotations featuresimonpj@microsoft.com2008-10-301-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch, written by Max Bolingbroke, does two things 1. It adds a new CoreM monad (defined in simplCore/CoreMonad), which is used as the top-level monad for all the Core-to-Core transformations (starting at SimplCore). It supports * I/O (for debug printing) * Unique supply * Statistics gathering * Access to the HscEnv, RuleBase, Annotations, Module The patch therefore refactors the top "skin" of every Core-to-Core pass, but does not change their functionality. 2. It adds a completely new facility to GHC: Core "annotations". The idea is that you can say {#- ANN foo (Just "Hello") #-} which adds the annotation (Just "Hello") to the top level function foo. These annotations can be looked up in any Core-to-Core pass, and are persisted into interface files. (Hence a Core-to-Core pass can also query the annotations of imported things.) Furthermore, a Core-to-Core pass can add new annotations (eg strictness info) of its own, which can be queried by importing modules. The design of the annotation system is somewhat in flux. It's designed to work with the (upcoming) dynamic plug-ins mechanism, but is meanwhile independently useful. Do not merge to 6.10!
* Move some flags from the Makefile into module pragmasIan Lynagh2008-07-101-0/+4
|
* Remove code that isn't used now that we assume that GHC >= 6.4Ian Lynagh2008-06-201-10/+0
|
View Lorry Controller Status