#13604: ghci no longer loads dynamic .o files by default if they were built with -O -------------------------------------+------------------------------------- Reporter: George | Owner: dfeuer Type: bug | Status: new Priority: highest | Milestone: 8.2.2 Component: Compiler | Version: 8.2.1-rc1 Resolution: | Keywords: | RecompilationCheck Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3514 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): === Some summary === The essence of this ticket is explained quite well by Edward in comment:11. I don't think I agree with Edward about how the interpretation of `-fobject-code` should play into everything, but his essential points stand: 1. We want to be able to run `ghc --make` and be sure that we get compilation products entirely equivalent to compiling from scratch. 2. We want `ghci` (especially) to be able to load `-dynamic`-compiled modules even if those modules were compiled with slightly different options. The question of what "slightly different" means is really up to the user. === The solution === Fortunately, it looks like this is probably not hard! Currently, we use `fingerprintDynFlags` to calculate a fingerprint of all the dflags that it believes can affect the compilation result and (in `addFingerprints`) record that fingerprint in the `ModIface`. When we are compiling with flags that don't match, we recompile the dependencies. What we want to do, I believe, is record not only the fingerprint but also information about some of the individual options. Some thoughts: 1. A change in whether cost center profiling is enabled `gopt Opt_SccProfilingOn dflags` absolutely mandates recompilation. I believe we want users to be able to (selectively) ignore changes to - `-O` - `-fhpc` - `-fignore-asserts` - Automatic cost-center insertion (`-fprof-...`) I think we can do this by using one fingerprint for each of these options, or, even simpler, for each option and each module, either "This module and its dependencies use value X" or "At least one dependency uses a different value than this module". 2. I believe we're currently somewhat too conservative about language flags in general. For example, I wouldn't expect enabling `-X` + `DataKinds`, `AllowAmbiguousTypes`, `ExplicitNamespaces`, `ConstraintKinds`, `MultiParamTypeClasses`, `FunctionalDependencies`, `FlexibleInstances`, `FlexibleContexts`, `UndecidableInstances`, `TupleSections`, `TypeSynonymInstances`, `StandaloneDeriving`, `DefaultSignatures`, `NullaryTypeClasses`, `EmptyCase`, `MultiWayIf`, or `ConstrainedClassMethods` to be able to change the result of compiling any module that was successfully compiled before. For these options, we're really only interested if one of them is ''turned off'' that was previously ''turned on''. For these, rather than a proper fingerprint, we want to record, for each option and each module, whether the module or at least one of its dependencies was compiled with that flag. 3. We should consider fingerprinting the result of running the preprocessor(s) over the source. If the `-D`, `-U`, or `-I` options change, or an `#include`d file changes, we only need to recompile if the results of preprocessing have actually changed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13604#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler