Thread overview
[Issue 17740] ghost "internal" symbols show up sometimes
Oct 10
Mr. Smith
Oct 10
Mr. Smith
Oct 10
Mr. Smith
August 10
https://issues.dlang.org/show_bug.cgi?id=17740

--- Comment #1 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to Steven Schveighoffer from comment #0)
> Another example:

Wrong link, here it is: https://forum.dlang.org/post/exinpcxvpdsbazyawmyz@forum.dlang.org

--
August 10
https://issues.dlang.org/show_bug.cgi?id=17740

--- Comment #2 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
Well, it looks like it relates to directly assigning a non-null value to the _timezone member at compile time. The new TimeZone class declaration is not required. All you have to do to trigger it is to change line # 8996 at the bottom of std.datetime.systime from

    Rebindable!(immutable TimeZone) _timezone;
to

    Rebindable!(immutable TimeZone) _timezone = UTC();

Unfortunately, declaring a struct like

    struct S
    {
        Rebindable!(immutable TimeZone) _timezone = UTC();
    }

does not exhibit the problem. So, I don't know how to create a small test case that doesn't require the std.datetime code. But assigning UTC() like this before used to work. A backend bug on Windows prevened me from getting a similar PR merged where it added a new TimeZone class, and assigning UTC() in that case had exactly the same problem as I recall (certainly, assigning the new time zone class did, because that's what blocked the PR). But it worked perfectly fine on other OSes, and I'm fairly certain that I tried those changes again at some point, and the backend bug was gone - I just wanted to rework the changes, so they weren't committed. Regardless, it worked perfectly fine on non-Windows OSes previously. So, something about this broke in the last several releases. I'd have to do some research to figure out when it broke though.

--
August 12
https://issues.dlang.org/show_bug.cgi?id=17740

Jonathan M Davis <issues.dlang@jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang@jmdavisProg.co
                   |                            |m

--- Comment #3 from Jonathan M Davis <issues.dlang@jmdavisProg.com> ---
Okay. If it's a regression, it's an old one. I suspect that I just didn't hit it before, because I didn't run make checkwhitespace, and running the full unittest build doesn't hit it (at least, not on my machine). I tried back as far as 2.069.0, and directly assigning UTC() to _timezone still triggered the problem with running make whitespace.

--
October 10
https://issues.dlang.org/show_bug.cgi?id=17740

--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com> ---
A better reduced test case:

https://gist.github.com/MrSmith33/dc53d8cb6ce642fcb6dbc5863d029cec

Courtesy of MrSmith:

https://forum.dlang.org/post/ahoyjzxreidgosqijrvu@forum.dlang.org

--
October 10
https://issues.dlang.org/show_bug.cgi?id=17740

Mr. Smith <mrsmith33@yandex.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrsmith33@yandex.ru

--- Comment #5 from Mr. Smith <mrsmith33@yandex.ru> ---
Here is even smaller test case:

// main.d
import texteditor;
void main() {}

// texteditor.d
module texteditor;
class EditorTextModel
{
    void fun() { editor.fun2(); }
    TextEditor editor;
}
struct TextEditor
{
    Piece* sentinel = new Piece;
    void fun2() {}
    import std.datetime : MonoTime;
}
struct Piece {}

// dmd -m64 -lib -of="lib.lib" -debug -g -w  -I="./" texteditor.d // dmd -m64 -of="app.exe" -debug -g -w -I="./" lib.lib main.d

--
October 10
https://issues.dlang.org/show_bug.cgi?id=17740

--- Comment #6 from Mr. Smith <mrsmith33@yandex.ru> ---
Looks like the problem is with
    Piece* sentinel = new Piece;
If I do that at runtime it works.

--
October 10
https://issues.dlang.org/show_bug.cgi?id=17740

--- Comment #7 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Hm... I didn't see this before, but you have an import for MonoTime. On the original PR I saw this, it was an update to MonoTime.

Can you confirm that your code works or not without MonoTime import (which seems to be doing nothing in your latest version)?

--
October 10
https://issues.dlang.org/show_bug.cgi?id=17740

--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> ---
Correction: PR was not about MonoTime but SysTime. But still, datetime seems to be involved.

--
October 10
https://issues.dlang.org/show_bug.cgi?id=17740

--- Comment #9 from Mr. Smith <mrsmith33@yandex.ru> ---
Error doesn't happen when `import std.datetime : MonoTime;` is removed

--