[Issue 17740] ghost "internal" symbols show up sometimes

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P3

--

[Issue 17740] ghost "internal" symbols show up sometimes

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #9 from Mr. Smith  ---
Error doesn't happen when `import std.datetime : MonoTime;` is removed

--

[Issue 17740] ghost "internal" symbols show up sometimes

[d-bugmail--- via Digitalmars-d-bugs]

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

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

--

[Issue 17740] ghost "internal" symbols show up sometimes

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #7 from Steven Schveighoffer  ---
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)?

--

[Issue 17740] ghost "internal" symbols show up sometimes

[d-bugmail--- via Digitalmars-d-bugs]

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

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

--

[Issue 17740] ghost "internal" symbols show up sometimes

[d-bugmail--- via Digitalmars-d-bugs]

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

Mr. Smith  changed:

   What|Removed |Added

 CC||mrsmit...@yandex.ru

--- Comment #5 from Mr. Smith  ---
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

--

[Issue 17740] ghost "internal" symbols show up sometimes

[d-bugmail--- via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
A better reduced test case:

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

Courtesy of MrSmith:

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

--

[Issue 17740] ghost "internal" symbols show up sometimes

[via Digitalmars-d-bugs]

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

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #3 from Jonathan M Davis  ---
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.

--

[Issue 17740] ghost "internal" symbols show up sometimes

[via Digitalmars-d-bugs]

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

--- Comment #2 from Jonathan M Davis  ---
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.

--

[Issue 17740] ghost "internal" symbols show up sometimes

[via Digitalmars-d-bugs]

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

--- Comment #1 from Steven Schveighoffer  ---
(In reply to Steven Schveighoffer from comment #0)
> Another example:

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

--