From 3897d02a5c0deb5c3bfda3299a28bbef525eba84 Mon Sep 17 00:00:00 2001 From: Simon Marlow Date: Wed, 9 Jul 2008 11:08:30 +0000 Subject: [PATCH] #1205: ':load foo.hs' in GHCi always compiles to bytecode So now :load foo.hs loads bytecode for foo.hs, even if foo.o exists :load foo is just shorthand for :load foo.hs :load M loads a module M, as object code if possible (no change here) :set -fobject-code :load foo.hs loads foo.hs as object code; an existing foo.o can be used. This turned out to be very straightforward: when building the ModSummary for a file (summariseFile) we just ignore the object file unless -fobject-code is on. --- compiler/main/GHC.hs | 12 ++++++++++-- docs/users_guide/ghci.xml | 36 +++++++++++++++++++++++++----------- 2 files changed, 35 insertions(+), 13 deletions(-) diff --git a/compiler/main/GHC.hs b/compiler/main/GHC.hs index f08b613..dbf3680 100644 --- a/compiler/main/GHC.hs +++ b/compiler/main/GHC.hs @@ -1757,7 +1757,10 @@ summariseFile hsc_env old_summaries file mb_phase maybe_buf if ms_hs_date old_summary == src_timestamp then do -- update the object-file timestamp - obj_timestamp <- getObjTimestamp location False + obj_timestamp <- + if isObjectTarget (hscTarget (hsc_dflags hsc_env)) -- #1205 + then getObjTimestamp location False + else return Nothing return old_summary{ ms_obj_date = obj_timestamp } else new_summary @@ -1785,7 +1788,12 @@ summariseFile hsc_env old_summaries file mb_phase maybe_buf Nothing -> getModificationTime file -- getMofificationTime may fail - obj_timestamp <- modificationTimeIfExists (ml_obj_file location) + -- when the user asks to load a source file by name, we only + -- use an object file if -fobject-code is on. See #1205. + obj_timestamp <- + if isObjectTarget (hscTarget (hsc_dflags hsc_env)) + then modificationTimeIfExists (ml_obj_file location) + else return Nothing return (ModSummary { ms_mod = mod, ms_hsc_src = HsSrcFile, ms_location = location, diff --git a/docs/users_guide/ghci.xml b/docs/users_guide/ghci.xml index e0ea3af..c5b5f7c 100644 --- a/docs/users_guide/ghci.xml +++ b/docs/users_guide/ghci.xml @@ -202,12 +202,12 @@ Ok, modules loaded: Main. very often, and use the interpreter for the code being actively developed. - When loading up source files with :load, - GHCi looks for any corresponding compiled object files, and will - use one in preference to interpreting the source if possible. For - example, suppose we have a 4-module program consisting of modules - A, B, C, and D. Modules B and C both import D only, - and A imports both B & C: + When loading up source modules with :load, + GHCi normally looks for any corresponding compiled object files, + and will use one in preference to interpreting the source if + possible. For example, suppose we have a 4-module program + consisting of modules A, B, C, and D. Modules B and C both import + D only, and A imports both B & C: A / \ @@ -298,6 +298,17 @@ Compiling A ( A.hs, interpreted ) Ok, modules loaded: A, B, C, D. + The automatic loading of object files can sometimes lead to + confusion, because non-exported top-level definitions of a module + are only available for use in expressions at the prompt when the + module is interpreted (see ). For + this reason, if you ask GHCi to load a filename rather than a + module name (e.g. :load Main.hs rather than + :load Main) then any existing object file will + be ignored and the module will be interpreted rather than + compiled. Using -fobject-code disables this + behaviour (see ). + HINT: since GHCi will only use a compiled object file if it can be sure that the compiled version is up-to-date, a good technique when working on a large program is to occasionally run @@ -306,7 +317,6 @@ Ok, modules loaded: A, B, C, D. interpreter. As you modify code, the changed modules will be interpreted, but the rest of the project will remain compiled. - @@ -537,10 +547,14 @@ Compiling Main ( Main.hs, interpreted ) scopes from multiple modules, in any mixture of * and non-* forms. GHCi combines the scopes from all of these modules to form the scope - that is in effect at the prompt. For technical reasons, GHCi - can only support the *-form for modules which - are interpreted, so compiled modules and package modules can - only contribute their exports to the current scope. + that is in effect at the prompt. + + NOTE: for technical reasons, GHCi can only support the + *-form for modules that are interpreted. + Compiled modules and package modules can only contribute their + exports to the current scope. This is why GHCi will always + interpret, not compile, a module if you specify its filename + rather than its module name to :load. The scope is manipulated using the :module command. For example, if the current -- 1.7.10.4