Difference between revisions of "Reporting LDC issues"
Klickverbot (talk | contribs) m (→Which issues to report?) |
Klickverbot (talk | contribs) |
||
Line 7: | Line 7: | ||
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. | 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 | + | 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 optimization passes. |
== What information to include? == | == What information to include? == | ||
Line 15: | Line 15: | ||
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. | 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, | + | That being said, in order to efficiently handle bug reports, '''it is crucial that the developers know the environment''' you are using LDC, '''in particular the LDC version/revision''' in which you are encountering the issue. In order to streamline the process, you might thus want to use the following bug report template (in cases where it makes sense, please don't forget to use your intuition): |
<pre> | <pre> |
Revision as of 09:52, 13 February 2013
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 optimization 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, it is crucial that the developers know the environment you are using LDC, in particular the LDC version/revision in which you are encountering the issue. In order to streamline the process, you might thus want to use 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: