Version 79 (modified by thoughtpolice, 4 years ago) (diff)


Release plans for GHC 7.8


We would like to fix all of the high and highest priority tickets in the 7.8.1 milestone, but there are currently a lot of them so this seems optimistic. Please feel free to take a ticket and help us!

Note that anything not listed here is off Austin's radar.

Completed new features

The features already completed are documented in the release notes: docs/users_guide/7.8.1-notes.xml

Pending things to completion

  • Austin Seipp needs to upload the primops compatibility package for 7.8. This is is easy: mostly a copy of compiler/utils/ExtsCompat64.hs into a Cabal package. See also the compatibility module page.
  • Austin also still has a lingering patch for #7602 to fix a large OS X performance regression, but it's still not merged. The basic gist is that the patch as written works for OS X 10.8. But in OS X 10.9 the TLS implementation changed, invalidating it, so some investigation is needed.
  • -XTemplateHaskell should now imply -dynamic-too, based on the discussions in #8180. Austin is attempting to fix this by switching it on during module loading but it doesn't quite work yet.
  • Pattern synonyms will make it! Austin will merge them Real Soon Now, after making sure there's documentation, Haddock works, and the T's are crossed and I's dotted.
  • New Haddock parser will hopefully go in, but isn't guaranteed yet. Austin will work with Mateusz to try and get it in ASAP.

The Windows Conundrum

  • Dynamic GHCi (#3658). This is working in HEAD, and enabled if DYNAMIC_GHC_PROGRAMS=YES, which causes GHC itself to be built dynamically. Currently it's enabled by default if dynamic libraries are supported, except for FreeBSD and Windows. On Windows, there are a few problems:
    • -dynamic-too doesn't work on Windows (#8228)
    • Because of #8228, GHC is a bit nerfed in using lots of RAM - see the discussion in #7134. We should fix -dynamic-too to knock out two birds with one stone (fix #7134 and enable using lots of RAM.)
    (Related but not critical: we have too many DLL symbols, and are very close to the limit (#5987). Linking also takes a long time (#8229)) The plan is/was to use dynamic GHCi on as many platforms as possible in 7.8, and to remove support for non-dynamic-ghci in HEAD soon after. See discussion in #8039, however.
  • Windows is becoming increasingly weird. It seems that with ./validate settings, a 32bit GHC built using the MSYS2 instructions mysteriously segfaults inside the stage2 compiler. But a 64bit GHC seems to work OK. But then as Austin was writing this it broke mysteriously, seemingly with no intervention.

  • Also, it seems as if -dynamic actually is broken in some weird way on Windows. During my (Austin) investigation into #8228, compiling a simple dynamic executable seems to result in segfaults. The most bizarre part is the .exe generated with -dynamic seems to depend on both libHSrts.dll and libHSrts_thr.dll! Without either in a place where the Windows linker can find it, the executable fails to start. Austin believes this is possibly the culprit (symbols may somehow get confused based on loading order,) but he doesn't know why -dynamic on windows seems to cause a dependency on both the threaded and non-threaded runtime.