I've found 2 internal compiler errors so far, but they have been occurring in very complex circumstances that I haven't been able to isolate within reasonable time frames (~ 1 hour).

https://github.com/etcimon/dmd/commit/32f2b44c8c126243f9c4ff00b89b175c9e596e7f

https://github.com/D-Programming-Language/dmd/commit/ca333f4b320223cc7d3779471cd27bb43af2f84a

In each case, simply showing the error with ::error allowed me to debug the source code and the ICE was not justified at all.

Is there a way to fast track the specific category (error handling) of ICE in DMD to avoid forcing me to waste more time isolating the bug?

On 2014-12-11 14:53:57 +0000, Etienne said:

> I've found 2 internal compiler errors so far, but they have been occurring in very complex circumstances that I haven't been able to isolate within reasonable time frames (~ 1 hour).
> 
> https://github.com/etcimon/dmd/commit/32f2b44c8c126243f9c4ff00b89b175c9e596e7f
> 
> https://github.com/D-Programming-Language/dmd/commit/ca333f4b320223cc7d3779471cd27bb43af2f84a 
> 
> 
> In each case, simply showing the error with ::error allowed me to debug the source code and the ICE was not justified at all.
> 
> Is there a way to fast track the specific category (error handling) of ICE in DMD to avoid forcing me to waste more time isolating the bug?

Have you tried running Dustmite (https://github.com/CyberShadow/DustMite) to minimize a test case automatically?

"Etienne"  wrote in message news:m6cb67$2fa3$1@digitalmars.com...

> I've found 2 internal compiler errors so far, but they have been occurring in very complex circumstances that I haven't been able to isolate within reasonable time frames (~ 1 hour).
>
> https://github.com/etcimon/dmd/commit/32f2b44c8c126243f9c4ff00b89b175c9e596e7f
>
> https://github.com/D-Programming-Language/dmd/commit/ca333f4b320223cc7d3779471cd27bb43af2f84a
>
> In each case, simply showing the error with ::error allowed me to debug the source code and the ICE was not justified at all.
>
> Is there a way to fast track the specific category (error handling) of ICE in DMD to avoid forcing me to waste more time isolating the bug?

It really helps to have a minimal test case for the bug, otherwise it's difficult for reviewers to tell if the fix is in the correct place.  It should be fairly easy to reduce a larger project that fails on an assertion down to a small test case using dustmite (or even dub dustmite).  Once you have the test case, straightforward patches that fix ices are usually merged fairly quickly. 

On 2014-12-11 4:34 PM, Daniel Murphy wrote:
>
> It really helps to have a minimal test case for the bug, otherwise it's
> difficult for reviewers to tell if the fix is in the correct place.  It
> should be fairly easy to reduce a larger project that fails on an
> assertion down to a small test case using dustmite (or even dub
> dustmite).  Once you have the test case, straightforward patches that
> fix ices are usually merged fairly quickly.

I doubt dustmite could work for my use case. I develop the entire application before compiling, so I usually end up with 1000s of code errors to go through. Some IOCs turn up, so I usually have to tweak the compiler to keep on going. I'll run dustmite if I can reproduce after everything compiles.

On 2014-12-11 8:05 PM, Etienne wrote:
> errors to go through. Some IOCs turn up, so I usually have to tweak the

IOC should be ICE (internal compiler error). Brain runs slow at EOD ;)

"Etienne"  wrote in message news:m6df1k$11vl$1@digitalmars.com...

> I doubt dustmite could work for my use case. I develop the entire application before compiling, so I usually end up with 1000s of code errors to go through. Some IOCs turn up, so I usually have to tweak the compiler to keep on going. I'll run dustmite if I can reproduce after everything compiles.

Extra errors shouldn't be a problem, and in fact this ICE may only occur when it is preceded by another error.  Running dustmite with a script that greps for the failing assertion should work perfectly.