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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------

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: -------