On Friday, 15 June 2018 at 03:54:34 UTC, DigitalDesigns wrote:
> So, it should be very important to have some type of info that connects the error to what the compiler was doing. With large problems it is not easy to reduce to a test case that shows the problem directly.

In my experience as a layman as far as DMD internals go, a compiler stack trace generally does little to elucidate what the cause of the crash is, or especially what part of the program is responsible. Tools to reduce the input (DustMite, or Digger for regressions) are generally more effective.

> I think a debug build dmd would be the easiest way. It is built with the release version so they are identical... but it would help users to quickly help with compiler errors rather than having to go build the compiler themselves, etc.

FWIW, Digger can build debug DMD binaries with `-c build.components.dmd.debugDMD=true`.

On Friday, 15 June 2018 at 04:19:28 UTC, Vladimir Panteleev wrote:
> On Friday, 15 June 2018 at 03:54:34 UTC, DigitalDesigns wrote:
>> So, it should be very important to have some type of info that connects the error to what the compiler was doing. With large problems it is not easy to reduce to a test case that shows the problem directly.
>
> In my experience as a layman as far as DMD internals go, a compiler stack trace generally does little to elucidate what the cause of the crash is, or especially what part of the program is responsible. Tools to reduce the input (DustMite, or Digger for regressions) are generally more effective.

Irregardless, any information is better than none. Just because it is not effective does not mean it is useless. In some cases it could lead directly to the problem. So it is wrong to think that it shouldn't be done because it doesn't help in ALL cases. That is throwing out the baby with the bath water. The question should be not how to get rid of the baby but how to keep the water.


>> I think a debug build dmd would be the easiest way. It is built with the release version so they are identical... but it would help users to quickly help with compiler errors rather than having to go build the compiler themselves, etc.
>
> FWIW, Digger can build debug DMD binaries with `-c build.components.dmd.debugDMD=true`.

The point is to include a debug version because not everyone wants to build things and go through that trouble nor do they necessarily have the time. dmd is about 3MB. Adding a debug version, what, might cost 100mb? That is nothing in to days world! There really is no reason to not do it if one really wants to cover as many bases as possible for fixing compiler bugs! There really is no excuse, but people will give them. All it would take is for someone to add a few lines to the automatic build environment and viola! There would be another vector of attack... potentially very strong in some cases.

My experience with the D tools such as dustmite has not been friendly as it should. This might be because I use visual D though.