On 12/15/2011 4:16 AM, Jacob Carlborg wrote:
> I wonder if we can list breaking changes in a separate sections in the changelog.

Any bug fix is a breaking change - code can and does depend on bugs (often inadvertently).

On 12/15/2011 6:31 AM, Adrian wrote:
> Am 15.12.2011 12:31, schrieb Stephan:
>> On 15.12.2011 12:02, Adrian wrote:
>>> - for the crash to happen the project has to be compiled with the
>>> switches  -noboundscheck and -deps="bug.dep". if you omit one of them
>>> the crash wont show.
>>
>> sounds like this one i encountered last release already:
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=6951
>
> yes looks pretty much the same. Its total weired, because it seems to
> depend on code which is elsewhere.

How about adding your bug.zip to that report?

On 2011-12-15 20:25, Walter Bright wrote:
> On 12/15/2011 4:16 AM, Jacob Carlborg wrote:
>> I wonder if we can list breaking changes in a separate sections in the
>> changelog.
>
> Any bug fix is a breaking change - code can and does depend on bugs
> (often inadvertently).

In this particular case it could just have been a design decision that has changed. And BTW, deprecating typdef can't be considered a bug fix, that would be perfect for a list of breaking changes.

-- 
/Jacob Carlborg

On 15.12.2011 21:34, Jacob Carlborg wrote:
> On 2011-12-15 20:25, Walter Bright wrote:
>> On 12/15/2011 4:16 AM, Jacob Carlborg wrote:
>>> I wonder if we can list breaking changes in a separate sections in the
>>> changelog.
>>
>> Any bug fix is a breaking change - code can and does depend on bugs
>> (often inadvertently).
>
> In this particular case it could just have been a design decision that
> has changed. And BTW, deprecating typdef can't be considered a bug fix,
> that would be perfect for a list of breaking changes.

Deprecating typedef is in the list of changed features, not in the list of fixed bugs. Choosing which list things go in is sometimes a bit arbitrary, though.
Occasionally in the changelog, major breaking changes were shown in red. That hasn't happened for ages.

On 2011-12-15 22:28, Don wrote:
> On 15.12.2011 21:34, Jacob Carlborg wrote:
>> On 2011-12-15 20:25, Walter Bright wrote:
>>> On 12/15/2011 4:16 AM, Jacob Carlborg wrote:
>>>> I wonder if we can list breaking changes in a separate sections in the
>>>> changelog.
>>>
>>> Any bug fix is a breaking change - code can and does depend on bugs
>>> (often inadvertently).
>>
>> In this particular case it could just have been a design decision that
>> has changed. And BTW, deprecating typdef can't be considered a bug fix,
>> that would be perfect for a list of breaking changes.
>
> Deprecating typedef is in the list of changed features, not in the list
> of fixed bugs. Choosing which list things go in is sometimes a bit
> arbitrary, though.
> Occasionally in the changelog, major breaking changes were shown in red.
> That hasn't happened for ages.

Yes, I noticed typedef in the list, but in this case it would have been nice if it had its own section in the list. I know that typedef has been "deprecated" for a while but I had no idea it would be official in this release.

-- 
/Jacob Carlborg

On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright wrote:
> Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target.
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.057.zip
>
> A lot of people put a ton of effort into making this D's best release ever. Thanks!

I found a bug when slicing static arrays. It's not new to 2.057 but I totally forgot about it (my bad) and didn't simplify a test case.

auto x() {
   ubyte[4] a;
   return a;
}

auto y() {
   return x()[1..$];
}

void main() {
   y();
}

Gives:
Internal error: ..\ztc\cgcs.c 354

Is this known or should I file a bug?

On Friday, December 16, 2011 16:26:11 Christian Manning wrote:
> On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
> 
> wrote:
> > Highlights are use of XMM floating point registers in 64 bit targets, and now supporting OS X 64 as a target.
> > 
> > http://www.digitalmars.com/d/2.0/changelog.html http://ftp.digitalmars.com/dmd.2.057.zip
> > 
> > A lot of people put a ton of effort into making this D's best release ever. Thanks!
> 
> I found a bug when slicing static arrays. It's not new to 2.057 but I totally forgot about it (my bad) and didn't simplify a test case.
> 
> auto x() {
>     ubyte[4] a;
>     return a;
> }
> 
> auto y() {
>     return x()[1..$];
> }
> 
> void main() {
>     y();
> }
> 
> Gives:
> Internal error: ..\ztc\cgcs.c 354
> 
> Is this known or should I file a bug?

It may bhttp://d.puremagic.com/issues/show_bug.cgi?id=4414

I'd point out though that that is really bad code, which should probably give an error when you try and compile it (though it obviously shouldn't cause the compiler to ICE regardless).

http://d.puremagic.com/issues/show_bug.cgi?id=7087

- Jonathan M Davis

On Friday, 16 December 2011 at 16:43:29 UTC, Jonathan M Davis wrote:
> On Friday, December 16, 2011 16:26:11 Christian Manning wrote:
>> On Wednesday, 14 December 2011 at 07:05:25 UTC, Walter Bright
>> 
>> wrote:
>> > Highlights are use of XMM floating point registers in 64 bit
>> > targets, and now supporting OS X 64 as a target.
>> > 
>> > http://www.digitalmars.com/d/2.0/changelog.html
>> > http://ftp.digitalmars.com/dmd.2.057.zip
>> > 
>> > A lot of people put a ton of effort into making this D's best
>> > release ever. Thanks!
>> 
>> I found a bug when slicing static arrays. It's not new to 2.057
>> but I totally forgot about it (my bad) and didn't simplify a test
>> case.
>> 
>> auto x() {
>>   ubyte[4] a;
>>   return a;
>> }
>> 
>> auto y() {
>>   return x()[1..$];
>> }
>> 
>> void main() {
>>   y();
>> }
>> 
>> Gives:
>> Internal error: ..\ztc\cgcs.c 354
>> 
>> Is this known or should I file a bug?
>
> It may bhttp://d.puremagic.com/issues/show_bug.cgi?id=4414
>
> I'd point out though that that is really bad code, which should probably give an error when you try and compile it (though it obviously shouldn't cause the compiler to ICE regardless).
>
> http://d.puremagic.com/issues/show_bug.cgi?id=7087
>
> - Jonathan M Davis

It was just some mess around code, but I'll avoid it in the future, so thanks for pointing it out :)

It does indeed look to be the same problem as http://d.puremagic.com/issues/show_bug.cgi?id=4414
I should also point out that the appearance of the error is dependant on the slice size.

How about this as a better test case?

ubyte[4] a;
auto x() {
   return a;
}
void main() {
   auto b = x()[1..$];
}

On Friday, December 16, 2011 22:37:50 Christian Manning wrote:
> How about this as a better test case?
> 
> ubyte[4] a;
> auto x() {
> return a;
> }
> void main() {
> auto b = x()[1..$];
> }

That actually has exactly the same problem. You're slicing a temporary. You can't slice a static array unless it's an actual variable, or you're going to have problems. b points to a slice of a static array which doesn't exist anymore. It _might_ work depending on how the registers used and how the stack is laid out, but it's still a bad idea.

Regardless, the compiler shouldn't be ICEing though.

- Jonathan M Davis

On Friday, 16 December 2011 at 22:48:21 UTC, Jonathan M Davis wrote:
> That actually has exactly the same problem. You're slicing a temporary. You can't slice a static array unless it's an actual variable, or you're going to have problems. b points to a slice of a static array which doesn't exist anymore. It _might_ work depending on how the registers used and how the stack is laid out, but it's still a bad idea.

Ah I get it now, thanks.