www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6113] New: singletons in std.datetime are not created early enough

reply d-bugmail puremagic.com writes:
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



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
next sibling parent d-bugmail puremagic.com writes:
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



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6113


Brad Roberts <braddr puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr puremagic.com



---
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6113




PDT ---

merged in, since that fixes the problem with std.datetime. But there _is_ a


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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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



PDT ---
Fixed as far as std.datetime goes:
https://github.com/D-Programming-Language/phobos/commit/ba7d70b85802e5626708545c96e38f91fcf5c341



-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 08 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6113


Jose Garcia <jsancio gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6113




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
prev sibling parent d-bugmail puremagic.com writes:
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



PST ---
Well, like I said, this was fixed previously and is only a problem in the

changed to be lazily loaded thanks to some casting hackery, so this is no


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 25 2011