Reporting LDC issues

The single best way of contributing to any open source project is to pick an open issue and submitting a patch to fix it. But even if you are not interested in compiler development, you can still contribute to the LDC project by filing high-quality bug reports for any issue you encounter. This article details a few important aspects of what makes a bug report useful for the developers.

Which issues to report?

Actually, the most important point here is what kind of bugs not to report: As soon as you run into an issue with LDC, the first thing to do should be to check whether the corresponding DMD version also shows the same problem (see ldc2 -version for the DMD release your LDC build is based on). If so, do not open an issue on the LDC issue tracker. Instead, please file a bug at the general D Bugzilla. Once the problem has been addressed in DMD, the fix will also make its way into LDC.

But besides that, please report any and all issues where LDC does not respect the D specification, behaves in an unexpected way, or generates problematic code.

In particular, note that we are also keen to hear about cases where the binaries generated by LDC run any slower than the DMD-generated code, or the performance is significantly worse than GDC. In such cases, LDC likely contains a glitch annihilating the benefits of LLVM's elaborate optimizing passes.

What information to include?

The single most important piece of information for any compiler bug report is a test case allowing the developers to reproduce the issue in order to work on a fix. Ideally, you are able to provide a test case which is »reduced«, i.e. not longer than absolutely necessary for the bug to appear, without any external dependencies (such as Phobos!). For this, using a code minimization tool such as DustMite is highly recommended.

But even if you can't provide a test case which fits on a single screen page, please at least provide some instructions on how to reproduce the issue. Otherwise, your report will likely not even get looked at.

That being said, in order to efficiently handle bug reports, some other pieces of information about the environment in which the problem appears turn out to be important in many cases. In order to streamline the process, you might thus want to consider using the following bug report template (in cases where it makes sense, please don't forget to use your intuition):

System: <OS name/version, including distro name if any>
Architecture: <x86/x86_64/…>
LLVM: <version? from distro packages or compiled from source?>
LDC: <distro package/release package/compiled from sources>
LDC Git revision: <skip if not building from source>

Issue description:


Test case(s), stack traces and other relevant information: