Difference between revisions of "Reporting LDC issues"

From D Wiki
Jump to: navigation, search
m (Which issues to report?)
 
(5 intermediate revisions by 3 users not shown)
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 optimizing passes.
+
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, 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):
+
That being said, in order to efficiently handle bug reports, '''it is crucial that the developers know the environment''' you are using LDC in, '''particularly 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 apply common sense):
  
 
<pre>
 
<pre>
Line 29: Line 29:
 
Test case(s), stack traces and other relevant information:
 
Test case(s), stack traces and other relevant information:
 
</pre>  
 
</pre>  
 +
 +
== Submitting the issue ==
 +
 +
When you are ready to submit your issue to the LDC developers, head over to the [https://github.com/ldc-developers/ldc/issues issue tracker on GitHub], click on '''New Issue''', and fill out the form. A GitHub account will be required.
  
 
[[Category:LDC]]
 
[[Category:LDC]]

Latest revision as of 22:29, 13 May 2015

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, particularly 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 apply common sense):

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:

Submitting the issue

When you are ready to submit your issue to the LDC developers, head over to the issue tracker on GitHub, click on New Issue, and fill out the form. A GitHub account will be required.