Rename CmmCPS to CmmPipeline. Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Move control flow optimization to CmmCPS. Unfortunately, I couldn't remove all incidences of runCmmContFlowOpt from HscMain; in particular, there is a Cmm conversion testing facility which may run with only control flow optimizations, which I preserved the semantics of. Given the state of the current codegen, this code might be moribund anyway. Signed-off-by: Edward Z. Yang <ezyang@mit.edu>
Refactor SrcLoc and SrcSpan The "Unhelpful" cases are now in a separate type. This allows us to improve various things, e.g.: * Most of the panic's in SrcLoc are now gone * The Lexer now works with RealSrcSpans rather than SrcSpans, i.e. it knows that it has real locations and thus can assume that the line number etc really exists * Some of the more suspicious cases are no longer necessary, e.g. we no longer need this case in advanceSrcLoc: advanceSrcLoc loc _ = loc -- Better than nothing More improvements can probably be made, e.g. tick locations can probably use RealSrcSpans too.
Remove very dead Java backend code.
Merge remote branch 'origin/master' into monad-comp Conflicts: compiler/main/HscMain.lhs
Preliminary monad-comprehension patch (Trac #4370) This is the work of Nils Schweinsberg <mail@n-sch.de> It adds the language extension -XMonadComprehensions, which generalises list comprehension syntax [ e | x <- xs] to work over arbitrary monads.
Trim some trailing spaces
Change the way module initialisation is done (#3252, #4417) Previously the code generator generated small code fragments labelled with __stginit_M for each module M, and these performed whatever initialisation was necessary for that module and recursively invoked the initialisation functions for imported modules. This appraoch had drawbacks: - FFI users had to call hs_add_root() to ensure the correct initialisation routines were called. This is a non-standard, and ugly, API. - unless we were using -split-objs, the __stginit dependencies would entail linking the whole transitive closure of modules imported, whether they were actually used or not. In an extreme case (#4387, #4417), a module from GHC might be imported for use in Template Haskell or an annotation, and that would force the whole of GHC to be needlessly linked into the final executable. So now instead we do our initialisation with C functions marked with __attribute__((constructor)), which are automatically invoked at program startup time (or DSO load-time). The C initialisers are emitted into the stub.c file. This means that every time we compile with -prof or -hpc, we now get a stub file, but thanks to #3687 that is now invisible to the user. There are some refactorings in the RTS (particularly for HPC) to handle the fact that initialisers now get run earlier than they did before. The __stginit symbols are still generated, and the hs_add_root() function still exists (but does nothing), for backwards compatibility.
Merge _stub.o files into the main .o file (Fixes #3687 and #706) Now GHC still generates the _stub.c files, but the object file is automatically merged into the main .o file for a module. This means that build systems (including GHC's own) no longer need to worry about looking for _stub.o files and including them when linking. I had to do lots of refactoring in DriverPipeline to make this work; now there's a monad to carry around all the information, and everything is a lot tidier. The _stub.c is now created as a temporary file and removed after compilation (unless the -keep-tmp-files flag is on).
Make compilation of hscRnImportDecls conditional: fixes stage1 build
Use tcRnImports rather than rnImports with GHCi "import" statement: fixes #4832 The bug here was that just using rnImports does not ensure that any dependent orphan modules are loaded, so instances declared by such modules will not be usable from the GHCi command line after an "import". This did not affect the :m syntax because it takes a different code path and uses getModuleExports directly, which contains its own calls to the orphan-module loading stuff.
Split out "Raw Cmm" dump to its own flag -ddump-raw-cmm Previously, -ddump-cmmz was used to dump out the "Raw Cmm" right before it gets passed to the backends, as well as all of the intermediate phases in the new code generator. Unfortunately, there are a lot of intermediate phases, which means -ddump-cmmz takes a very long time with -fnew-codegen for large programs, even if you're only interested in the final result. Here we split up -ddump-cmmz into -ddump-cmmz (now exclusively for the new code generator) and -ddump-raw-cmm (for both code generation paths.) The old flag was not documented in the manual, so hopefully not too many people will be surprised by this change.
:script file scripts in GHCi #1363 This patch adds the script command in GHCi A file is read and executed as a series of GHCi commands. Execution terminates on the first error. The filename and line number are included in the error.
Added a VECTORISE pragma - Added a pragma {-# VECTORISE var = exp #-} that prevents the vectoriser from vectorising the definition of 'var'. Instead it uses the binding '$v_var = exp' to vectorise 'var'. The vectoriser checks that the Core type of 'exp' matches the vectorised Core type of 'var'. (It would be quite complicated to perform that check in the type checker as the vectorisation of a type needs the state of the VM monad.) - Added parts of a related VECTORISE SCALAR pragma - Documented -ddump-vect - Added -ddump-vt-trace - Some clean up
Merge in new code generator branch. This changes the new code generator to make use of the Hoopl package for dataflow analysis. Hoopl is a new boot package, and is maintained in a separate upstream git repository (as usual, GHC has its own lagging darcs mirror in http://darcs.haskell.org/packages/hoopl). During this merge I squashed recent history into one patch. I tried to rebase, but the history had some internal conflicts of its own which made rebase extremely confusing, so I gave up. The history I squashed was: - Update new codegen to work with latest Hoopl - Add some notes on new code gen to cmm-notes - Enable Hoopl lag package. - Add SPJ note to cmm-notes - Improve GC calls on new code generator. Work in this branch was done by: - Milan Straka <fox@ucw.cz> - John Dias <dias@cs.tufts.edu> - David Terei <davidterei@gmail.com> Edward Z. Yang <ezyang@mit.edu> merged in further changes from GHC HEAD and fixed a few bugs.
Change an "if ... else return ()" into a "when"
Fix import warning
Refactoring and tidyup of HscMain and related things (also fix #1666) While trying to fix #1666 (-Werror aborts too early) I decided to some tidyup in GHC/DriverPipeline/HscMain. - The GhcMonad overloading is gone from DriverPipeline and HscMain now. GhcMonad is now defined in a module of its own, and only used in the top-level GHC layer. DriverPipeline and HscMain use the plain IO monad and take HscEnv as an argument. - WarnLogMonad is gone. printExceptionAndWarnings is now called printException (the old name is deprecated). Session no longer contains warnings. - HscMain has its own little monad that collects warnings, and also plumbs HscEnv around. The idea here is that warnings are collected while we're in HscMain, but on exit from HscMain (any function) we check for warnings and either print them (via log_action, so IDEs can still override the printing), or turn them into an error if -Werror is on. - GhcApiCallbacks is gone, along with GHC.loadWithLogger. Thomas Schilling told me he wasn't using these, and I don't see a good reason to have them. - there's a new pure API to the parser (suggestion from Neil Mitchell): parser :: String -> DynFlags -> FilePath -> Either ErrorMessages (WarningMessages, Located (HsModule RdrName))
Clean up the debugger code In particular there is much less fiddly skolemisation now Things are not *quite* right (break001 and 006 still fail), but they are *much* better than before.
Remove GHC.extendGlobalRdrScope, GHC.extendGlobalTypeScope These functions were added by Tue Apr 18 03:36:06 BST 2006 Lemmih <lemmih@gmail.com> * Make the initial rdr and type scope available in the ghc-api The are extremely dubious, because they extend the Rdr and Type env for every compilation. The right thing to do is to use the InteractiveContext for temporary extensions. So far as we know, no one uses them. And if they are being used it's probably a mistake. So we're backing them out.