digitalmars.D.bugs - [Issue 6113] New: singletons in std.datetime are not created early enough
- d-bugmail puremagic.com (36/36) Jun 05 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6113
- d-bugmail puremagic.com (15/15) Jun 05 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6113
- d-bugmail puremagic.com (14/14) Jun 06 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6113
- d-bugmail puremagic.com (14/14) Jun 06 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6113
- d-bugmail puremagic.com (13/13) Jun 08 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6113
- d-bugmail puremagic.com (18/18) Sep 04 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6113
- d-bugmail puremagic.com (7/7) Sep 04 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6113
- d-bugmail puremagic.com (14/14) Dec 25 2011 http://d.puremagic.com/issues/show_bug.cgi?id=6113
http://d.puremagic.com/issues/show_bug.cgi?id=6113 Summary: singletons in std.datetime are not created early enough Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nobody puremagic.com ReportedBy: jsancio gmail.com --- Comment #0 from Jose Garcia <jsancio gmail.com> 2011-06-05 22:24:28 PDT --- When accessing the singletons from a shared static this module ctr, the singleton have not been instantiated. The following code succeeds when it shouldn't: import std.datetime; shared static this() { assert(UTC() is null); assert(LocalTime() is null); } A possible solution is: class Test { shared static this() { _obj = new immutable(shared(Object)); } shared static immutable Object _ojb; } shared static this() { assert(Test._ojb !is null); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 05 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6113 Jonathan M Davis <jmdavisProg gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Platform|Other |All OS/Version|Windows |All --- Comment #1 from Jonathan M Davis <jmdavisProg gmx.com> 2011-06-05 23:37:20 PDT --- There's now a pull request with the fixes: https://github.com/D-Programming-Language/phobos/pull/81 Given the simplicity of the change, I expect that it'll be merged in fairly quickly. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 05 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6113 Brad Roberts <braddr puremagic.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |braddr puremagic.com --- Comment #2 from Brad Roberts <braddr puremagic.com> 2011-06-06 00:00:14 PDT --- While changing them to shared static ctors is a good change, I there might well be a real bug here anyway. For the main thread's initialization, should it run through all shared static ctors then all non-shared static ctors as two passes? Or, should it run through all shared static and non-shared statics together in one pass? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 06 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6113 --- Comment #3 from Jonathan M Davis <jmdavisProg gmx.com> 2011-06-06 00:13:27 PDT --- That's why I opened bug# 6114. I'm going to close this one once my fix has been merged in, since that fixes the problem with std.datetime. But there _is_ a compiler bug here. Bug# 6114 covers that. Everything that I've read says that the static constructors are supposed supposed to be run in lexical order within a module, and the the compiler will order the initialization of the modules such that they're run in the order necessary to initialize everything before it's used. I haven't seen anything that would indicate that hared static constructors should be treated any differently from other static constructors as far as initialization order goes. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 06 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6113 Jonathan M Davis <jmdavisProg gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #4 from Jonathan M Davis <jmdavisProg gmx.com> 2011-06-08 09:01:06 PDT --- Fixed as far as std.datetime goes: https://github.com/D-Programming-Language/phobos/commit/ba7d70b85802e5626708545c96e38f91fcf5c341 The underlying problem ( bug# 6114 ) still exists though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jun 08 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6113 Jose Garcia <jsancio gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | --- Comment #5 from Jose Garcia <jsancio gmail.com> 2011-09-04 23:38:06 PDT --- Why was this closed? The following code still failed: import std.datetime; shared static this() { assert(UTC() !is null); assert(LocalTime() !is null); } void main() {} -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 04 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6113 --- Comment #6 from Jose Garcia <jsancio gmail.com> 2011-09-04 23:41:09 PDT --- While we are on the subject, does anyone have a suggestion on how to write unit test that test this? Or do we need to extend the unittest capability? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Sep 04 2011
http://d.puremagic.com/issues/show_bug.cgi?id=6113 Jonathan M Davis <jmdavisProg gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #8 from Jonathan M Davis <jmdavisProg gmx.com> 2011-12-25 18:14:05 PST --- Well, like I said, this was fixed previously and is only a problem in the current release due to bug# 6331. However, in git, UTC and LocalTime have been changed to be lazily loaded thanks to some casting hackery, so this is no longer an issue regardless of the state of bug# 6331. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 25 2011