Are these (known) bugs?

[biozic]

Le 29/01/11 03:51, Jonathan M Davis a écrit :
> On Friday 28 January 2011 13:55:03 Jonathan M Davis wrote:
>> On Friday, January 28, 2011 10:57:58 biozic wrote:
>>> Hi,
>>>
>>> I am playing with the to-be-released std.datetime, and encountered these
>>> errors (the last one concerns std.variant, actually), with dmd 2.052
>>> (Mac OS X 10.6):
>>>
>>> ---
>>> import std.array, std.datetime, std.variant;
>>>
>>> unittest {
>>>
>>>       auto app = appender!(Interval!Date[]);
>>>       auto interval = Interval!Date(Date(2000, 1, 1), Date(2011, 2, 3));
>>>       app.put(interval);
>>>       // Error: datetime.d(20208): Invariant Failure: begin is not before
>>>
>>> or equal to end.
>>> }
>> There no known bugs in std.datetime. My guess would be that the issue lies
>> with appender and Interval!(Date).init and/or something set to void if
>> appender does that at all. But since Date.init would be equal to
>> Date.init, it seems extremely bizarre that Interval!(Date).init would have
>> its begin and end not be equal, which makes it less likely that
>> Interval!(Date).init would be the problem. So, I don't know. The code is
>> very thoroughly tested, but that doesn't mean that I didn't miss
>> something, and it's possible that there's a bug in appender. I'm not at
>> all familiar with how appender works. I'll have to take a look at it
>> tonight.
>>
>> But std.datetime has a ton of unit tests and, as far as I know, is
>> currently passing all of them on Linux, Windows, and OS X (I don't know
>> about FreeBSD). The most likely problems would be on OS X or FreeBSD,
>> since I don't have a system with either OS X or FreeBSD, and there could
>> be problems in time zones other than America/Los_Angeles - particularly on
>> Windows where you can't easily test time zones other than the one that
>> you're in - since all of my development has been done in
>> America/Los_Angeles. But I'm not aware of any bugs. So, if you do find
>> problems, please report them.
> Okay. This is pretty much _has_ to be either a bug in appender or in the
> compiler. It happens non-derministically. The exact same program will sometimes
> work just fine and sometimes the invariant will fail. It almost has to be the
> case that the values being used were initialized with garbage data. It's the
> kind of thing that I'd expect if = void had been used. I don't see = void in the
> appender code, but it _is_ calling GC functions such as GC.extend and GC.qalloc.
> I don't know enough about appender or how those functions work, but I suspect
> that something isn't being properly initialized before it's used. Open a bug
> report on the issue. Someone with knowledge of appender is going to have to take
> a look at it.
>
> - Jonathan M Davis

Thanks for your answer. Indeed, the bug might concern 
garbage-initialized structs during appending. It is reducible to:

---
import std.array;

struct Foo {
     int a, b;

     Foo opAssign(Foo rhs) {
         a = rhs.a;
         b = rhs.b;
         return this;
     }

     invariant () {
         assert (a <= b);
     }
}

unittest {
     auto app = appender!(Foo[]);
     auto foo = Foo(1, 2);
     app.put(foo);
}
---

It involves calling an invariant() on a struct where opAssign is 
overloaded. You have filed a report concerning such a problem in issue 
#5058.