Last update October 21, 2012

Contributing To The D Compiler


The D compiler has one front end and three back-ends. Given that all back-ends share the same front-end, you should expect the same compatibility level across all compilers for a given compiler release. The back-ends are different in aspects such as speed of compilation, performance of generated code, and availability on various platforms.

The front-end is open-source. Depending on back-end, there are three offerings: dmd (the official implementation), gdc (uses the gcc backend), and ldc (uses the LLVM backend). The dmd compiler has a source-available but not open-source backend because it is licensed from Symantec. The gdc and llvm compilers are entirely open-source.

Most of the "language" work is in the shared front-end, which is hosted on github. (You'll also find there the base run-time library druntime, and the standard library phobos, but this page is concerned mainly with compiler changes.)

How to get your pull requests merged quickly

The following people have commit rights to dmd:

Namegithub handle
Andrei Alexandrescuandralex
Don Clugstondonc
Kenji Hara9rnsr
Daniel Murphyyebblies
Martin Nowakdawgfoto
Brad Robertsbraddr
Walter BrightWalterBright

No committer ever merges his own pull requests (i.e., everything must be reviewed), and anything that changes the language in any way must still be merged (or at least approved) by Walter. Obviously we will not merge anything which doesn't pass in the auto tester.

This means:

  1. If you write a compiler pull request, and it contains nothing controversial, it can be merged quickly. Anything remotely controversial should be submitted separately, and made as small as possible.
  2. Try to make the pull request easy to review. Don't mix cosmetic changes (whitespace, function or variable renaming) with anything else. Put some comments in the pull request to aid the reviewer. This is especially important if you're not a regular contributor. You might be changing part of the code that we've never touched -- you need to give us some confidence that you have some idea of what you're doing.
  3. Try to have a pull request address only one thing, and be self-contained. Don't mix unrelated commits into a single pull request (e.g. fix to one file and a documentation change of an unrelated file). Even simple changes like edits to the .gitignore file should be made in a separate pull request and not mixed with other commits.
  4. If a pull request fixes a bug in bugzilla, include a link to that bugzilla report. In the pull message, be sure and include the phrase "fix issue nnnn", where nnnn is the bugzilla number.
  5. Whenever a pull results in behavior changes (and of course, fixing a bug changes the behavior!), an addition to the test suite should be included that verifies the correct new behavior.
  6. Tests that check for compilation failure must each be in their own file to verify that each of them triggers compilation failure separately.
  7. When a pull results in changes/additions to diagnostic messages (e.g. compiler warnings or errors), you should edit existing and/or add new test-cases to verify the new behavior. See one of the 'diag1234.d' modules in dmd/test/fail_compilation for an example.
  8. If you're fixing a bug filed in the D Bugzilla make sure your commit message begins with Fixes Issue ### (replace ### with the issue number). This enables Github to automatically close the bug report when your pull request is merged.
  9. If you have multiple commits you should squash them. Here's how to do it. (Remember to start the commit message with Fixes Issue ### as stated above, when required). Note for win32 users: You might want to run git config --global core.editor "notepad" before calling rebase as the built-in editor might be hard to use. (notepad doesn't display unix newlines correctly though). A better win32 guide will be written ASAP.
Pull requests are automatically tested via the D2 auto-tester. But you should first try to run the test suite locally if you can.

Many contributors are concerned at the number of pull requests that are not yet merged. Given the way github works and the constraints we have, this is currently inevitable. (A large number of older pull requests are language enhancements). There are also a fair number of pull requests that are not controversial but are difficult to review, either because they modify a lot of code, or because they lack explanation of how they work. And of course there are quite a few that fail the tests.

Making Pull Requests

See the Pull Request guide.

FrontPage | News | TestPage | MessageBoard | Search | Contributors | Folders | Index | Help | Preferences | Edit

Edit text of this page (date of last change: October 21, 2012 20:19 (diff))