Resources for newcomers to GHC

This page is intended to serve as the first stop for those people who say, "I want to contribute to GHC, but I don't know quite where to begin." Begin here. While the working conventions page has great information that can come in handy while you're working on your first, or first several patches, this page is intended to have the details you will need to get rolling.

First steps

  • To orient yourself to the general architecture of GHC, this article, written by two of the chief architects of GHC, Simon Marlow and Simon Peyton-Jones, is excellent and current (2012).
  • While you're reading that article, download and build the sources. Prepare your machine, download the source, and build. For the short, short version, which may or may not work for your machine, you can try this:
# needed only once, URL rewrite rule is persisted in ${HOME}/.gitconfig
git config --global url."git://".insteadOf git:// 

# clone GHC's main Git repository (creates './ghc' folder in CWD)
git clone --recursive git://
cd ghc/
git clone git://  # Windows only

# configure build
cd mk
## edit to remove the comment marker # on the line "BuildFlavour = quick"
cd ..
perl boot

# build GHC
make -j8 # parallelize to at most 8 parallel jobs; adapt to actual number of cpu cores
## edit to remove the comment marker # on the line stage=2

replace git:// by http:// or https:// in the instructions above if you're behind a firewall blocking port 9418. For more details see also Building/GettingTheSources.

If your machine has all the prerequisites, this might just work. Expect it all to take roughly an hour.

  • After a successful build, you should have your brand new compiler in ghc/inplace/bin/ghc-stage2. (GHCi is launched with ghc/inplace/bin/ghc-stage2 --interactive). Try it out.
  • The final edit of makes sure that only the stage-2 compiler will be build after this (see here about stages). This will be much faster, and usually what you want. If, for some reason, you're working on the stage-1 compiler, you can undo that change and use make 1, but you must be in the compiler subdirectory, not the ghc subdirectory.
  • A good first sanity check is to twiddle some error message in the code, just to see that changed error message pop up when you compile a file. Write some Haskell code with an error in it, and look at the error message. Search through the ghc code for that error message (almost all the relevant code is in the compiler/ subdirectory of ghc). Change the message, and then rebuild (run make in the ghc subdirectory of ghc -- that is, ghc/ghc). If you see the changed message, you're good to go.
  • If you've made it this far, you're well on your way to becoming a GHC developer. You should subscribe to the ghc-devs mailing list.

Fixing a bug

Below is a list of bugs that appear to be "low-hanging fruit" -- things that might be reasonable for a newcomer to GHC hacking. Of course, we can't ever be sure of how hard a task is before doing it, so apologies if one of these is too hard.

Separate warnings for unused local and top-level bindings
RecursiveDo in Template Haskell
The -> in ViewPatterns binds more weakly than infix data constructors.
Selective disabling of unused bind warnings
Allow local foreign imports
Wildcards in type functions
Type family patterns should support as-patterns.
Easy way to defer type errors
Profiling output jumbled together
TH pretty printer and GHC parser semicolon placement mismatch
make sdist picks up test files
ghc does not expose branchless max/min operations as primops
"\n" is displayed weirdly in error messages
Show data/type family instances with ghci's :info command
Give Tab warning only once per file

Once you fix the bug, make sure to write a test-case proving that you've done what you said. Then take some time to get to know and submit a code review to Phabricator. If the patch looks good, one of the committers will put it into the GHC codebase. Then, tackle another bug!

Practical advice

  • This page describes in more detail workflow for fixing bugs.
  • I (Richard E) use emacs to edit the code, and I have a hotkey dedicated to searching the ghc codebase, and another one dedicated to compiling ghc. This makes work on ghc much more interactive. See the Emacs page for more info.

Less practical advice

  • Don't get scared. GHC is a big codebase, but it makes sense when you stare at it long enough!
  • Be forewarned that many pages on the GHC wiki are somewhat out-of-date. Always check the last modification date. Email if you're not sure.

Need help?

You can email the ghc-devs list, or Richard Eisenberg (eir at cis . upenn . edu), a newish GHC developer himself who would be happy to foster more participation and answer your emails.

Happy hacking!

Last modified 4 months ago Last modified on Nov 13, 2014 1:53:00 PM