Ghc bugs

We keep track of the discovered GHC bugs and inconvenient features, in particular, to know what we have to work around depending on which version of GHC we deploy with. Issues that still require fixes in the GHC code proper are marked with (*). See also the corresponding fpco repo wiki page.

• setSessionDynFlags does not always work

  Worked around for 7.4.2 and 7.6.1, fixed in 7.6.2, workaround ifdefed.

• GHC API displays linker messages to stdout instead of via log_action (*)

  Worked around for all versions by suppressing stdout during compilation and setting GHC verbosity to 0 during execution. Fixed upstream in 7.8.1. Workaround are marked with comments, but not ifdefed, because they are a sensible precaution against any other kinds of stray output that may crop up in the future. A related problem is that the error is a string blob instead of a structured output that we can easily process and that log_action usually provides. See also a recent discussion about the linker messages.

• GHC API reports CPP errors in confusing ways (*)

  Partially worked around for all versions by capturing the errors and merging them with standard errors. Not fixed upstream yet. There may be other, similar cases where the workaround helps. The workaround code is not particularly hacky, just not perfectly effective, so it makes sense to keep it even after the original problem is fixed, so not ifdefing the workaround to any specific GHC version nor marking it in the code in any way.

• getModificationTime gives only second-level resolution

  Worked around for all versions (tested on 7.4.2), fixed in 7.8.1 for Linux only. The workaround code is contained to IdeSession.hs, but it has to be all over the place, so ifdefing it would make the file much less readable and would require nontrivial maintenance. When we switch to GHC >= 7.8 we have to either get rid of the workaround or ifdef its most recent version, if we really need to.

• We need to disable or fix GHC's debugging facility in order to be able to interrupt code

  GHC does not give us an explicit API for terminating code started using runStmt. The workaround is described in the ticket but requires that we disable the GHC debugging facility, which eventually turned out not to be good enough. This is presumably fixed for 7.8.1 and now it's fixed in our custom ghc in "Provide access to the TID of the runStmt sandbox" (https://github.com/fpco/ghc/commit/2684a8f9aeaec8189e4ebbc01fe657469253d9e8).

• GHC may crash with a hard crash when attempting to run uncompiled code (*)

  This is not a major problem, because we can guard against this in ide-session, but when we don't (because of a bug or otherwise) it makes for some difficult debugging. No workaround as such is needed, so the code is not ifdefed either.

• We have no high-level way of resetting the Handles (*)

  Not sure if this is an API bug per say; see Issue 24 and the corresponding commit. Anyway, the workaround is so extensive (involves extra packages, etc.) that ifdefing or marking the workaround code is not practical.

• GHC API dependency analysis is broken

  Patched in our custom GHC and ifdefed not to compile with GHC 7.6.1, where it's not patched, but works OK with GHC >= 7.6.2. It is fixed upstream for 7.6.2 as GHCi erroneously unloads modules after a failed :reload.

• invalidateModSummaryCache throws exception if ms_hs_date is 0

  We work around a GHC bug where dynamic flags are not set correctly by manually calling invalidateModSummaryCache, which we borrowed from upstream. We work around another GHC bug (using only 1s resolution in checking which modules need updating) by manually setting "logical timestamps". We start counting with these logical timestamps at 0, but invalidateModSummary cache works by subtracting 1 from the file's timestamp, thus yielding the exception (the exception may or may not be thrown depending on which timezone is set). We workaround this problem by starting at a larger value than 0.

• GHC caches the module name to file name mapping as described in an ide-backend commit message

  Consequently, e.g., the result of subsequent compilations is different than when a session is restarted from scratch. This is against our API invariant that hidden session state can be wiped out and recreated at will. Generally this is related to GHC ad-hoc and patchy enforcement of the file names vs module names discipline.

• GHC does not unload a module when its import section is changed to be incorrect, as reproduced in an ide-backend test

  This is confusing to users, because any other errors lead to the unloading of incorrect modules and users can observe it by running currently loaded code.

• GHC does not preserve anywhere the versions of wired-in packages. Currently, the only way to recover the versions is by invoking 'show' on an InstalledPackageId of a wired package and then parsing the resulting string. This is fragile, since the format of the string is not formally specified (neither the string inside the constructor of the opaque type InstalledPackageId nor the string generated by the Show instance). The format can change along with GHC changes, as well as Version and Cabal package changes.

  17:36 < dcoutts> now, in my not so humble opinion, ghc should use the InstalledPackageId internally
  everywhere, and use a different mechanism for looking up builtin names from wired in packages
  17:36 < dcoutts> using a separate "wired-in package name" -> InstalledPackageId mapping, just for that purpose.
  

* To collect compilation info, we need much more powerful GHC plugins. This is implemented in our custom ghc as 'Add support for "frontend plugins"' (https://github.com/fpco/ghc/commit/d218c93b19490f9e15ccf87f2ea72188511aea3c and some others).

* GHC has to be tweaked to pass renamer results through typechecker. (Done in https://github.com/fpco/ghc/commit/027b97e4075f20bfcf4151c33f34b03bab7bdf32 .)
    
* [The SrcSpan for the expansion of quasi-quotes is not consistent](http://hackage.haskell.org/trac/ghc/ticket/7918)