[source]

compiler/main/GhcMake.hs

Note [Missing home modules]

[note link]

Sometimes user doesn’t want GHC to pick up modules, not explicitly listed in a command line. For example, cabal may want to enable this warning when building a library, so that GHC warns user about modules, not listed neither in exposed-modules, nor in other-modules.

Here “home module” means a module, that doesn’t come from an other package.

For example, if GHC is invoked with modules “A” and “B” as targets, but “A” imports some other module “C”, then GHC will issue a warning about module “C” not being listed in a command line.

The warning in enabled by -Wmissing-home-modules. See #13129

Note [-fno-code mode]

[note link]

GHC offers the flag -fno-code for the purpose of parsing and typechecking a program without generating object files. This is intended to be used by tooling and IDEs to provide quick feedback on any parser or type errors as cheaply as possible.

When GHC is invoked with -fno-code no object files or linked output will be generated. As many errors and warnings as possible will be generated, as if -fno-code had not been passed. The session DynFlags will have hscTarget == HscNothing.

-fwrite-interface

Whether interface files are generated in -fno-code mode is controlled by the -fwrite-interface flag. The -fwrite-interface flag is a no-op if -fno-code is not also passed. Recompilation avoidance requires interface files, so passing -fno-code without -fwrite-interface should be avoided. If -fno-code were re-implemented today, -fwrite-interface would be discarded and it would be considered always on; this behaviour is as it is for backwards compatibility.

IN SUMMARY: ALWAYS PASS -fno-code AND -fwrite-interface TOGETHER

Template Haskell

A module using template haskell may invoke an imported function from inside a splice. This will cause the type-checker to attempt to execute that code, which would fail if no object files had been generated. See #8025. To rectify this, during the downsweep we patch the DynFlags in the ModSummary of any home module that is imported by a module that uses template haskell, to generate object code.

The flavour of generated object code is chosen by defaultObjectTarget for the target platform. It would likely be faster to generate bytecode, but this is not supported on all platforms(?Please Confirm?), and does not support the entirety of GHC haskell. See #1257.

The object files (and interface files if -fwrite-interface is disabled) produced for template haskell are written to temporary files.

Note that since template haskell can run arbitrary IO actions, -fno-code mode is no more secure than running without it.

Potential TODOS:

  • Remove -fwrite-interface and have interface files always written in -fno-code mode
  • Both .o and .dyn_o files are generated for template haskell, but we only need .dyn_o. Fix it.
  • In make mode, a message like Compiling A (A.hs, /tmp/ghc_123.o) is shown if downsweep enabled object code generation for A. Perhaps we should show “nothing” or “temporary object file” instead. Note that one can currently use -keep-tmp-files and inspect the generated file with the current behaviour.
  • Offer a -no-codedir command line option, and write what were temporary object files there. This would speed up recompilation.
  • Use existing object files (if they are up to date) instead of always generating temporary ones.

Note [Recompilation checking in -fno-code mode]

[note link]

If we are compiling with -fno-code -fwrite-interface, there won’t be any object code that we can compare against, nor should there be: we’re just generating interface files. In this case, we want to check if the interface file is new, in lieu of the object file. See also #9243.

Filter modules in the HPT