On Fri, Aug 30, 2013 at 12:43:44PM -0700, Walter Bright wrote: > On 8/30/2013 11:32 AM, H. S. Teoh wrote: [...] > >I obtained a +1 Sword of Bisection from a git this morning, and > >decided to go commit hunting. I found the specific commits that > >introduced the following regressions (see bug notes for the offending > >commits): > > > >10687 - Refused cast from uint[] to array of uint-based enums at compile-time > >10401 - ICE(ztc/symbol.c 1035) - inline Nullable struct with JSONValue > >10425 - Link error with templates > >10555 - enumerator can no longer increment beyond maximum of initializer > >10617 - contract with -profile -debug is not nothrow > >10630 - Structs with disabled default construction can't be used as `out` > >parameters > > > >I would fix them myself, except that my dmd-fu level isn't high > >enough to take them on yet. ;-) > > Thank you. This is great information.
And easily obtained with git bisect, about 5-10 minutes per bug. :) On Fri, Aug 30, 2013 at 12:45:16PM -0700, Walter Bright wrote: [...] > BTW, please add this information to both the regression issues and > the issues who's resolution introduced the regression. Done. The bugs whose resolution introduced the regressions were pretty easy to find, except for 10687: I had to read up on how to work with complicated git revision ranges to isolate it. :) Turns out it's another regression from Don's epic pull: https://github.com/D-Programming-Language/dmd/pull/2136 Unfortunately, for all of its epicness, a change of such magnitude inevitably introduces/exposes other flaws, and this is one of them (already the second one noted on the pull page). One of these days I'll have to research a little more how to more easily identify the merge commit that pulled in a particular commit. Since all commits only refer to their ancestors, git has no easy way of following the chain downstream to the merge point (at least, none that I know of). If anyone knows some git-fu to do this, I'd be very much obliged. :) T -- Кто везде - тот нигде.