www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11714] New: Improve error message for wrongly initialized thread-local class instances

reply d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714

           Summary: Improve error message for wrongly initialized
                    thread-local class instances
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: joseph.wakeling webdrake.net



2013-12-10 02:45:33 PST ---
If a developer tries to initialize a static/thread-local class instance with a
value not knowable at compile time, the compiler will object with an error
message as follows:

    Error: variable %s is mutable. Only const or immutable class thread local
variable are allowed, not %s

This easily leads to the wrong conclusion that thread-local class instances
must themselves be const or immutable, rather than the reality that the
initialization value must be.

This error message should be replaced with something more friendly, along the
lines of

    Cannot initialize thread-local class variable %s with a mutable value. 
Only const or immutable initial values are allowed (e.g. null).

Background:
http://forum.dlang.org/post/mailman.408.1386663198.3242.digitalmars-d-learn puremagic.com

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 10 2013
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714




2013-12-10 02:47:36 PST ---
Pull request with fix (slightly different message from the one suggested here):
https://github.com/D-Programming-Language/dmd/pull/2943

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714




2013-12-10 09:13:13 PST ---
Created an attachment (id=1300)
Test case for the existing error message.  To see, run rdmd -main tlclass.d

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714




2013-12-10 09:14:48 PST ---
The attached test case illustrates the error, in this case:

    tlclass.d(8): Error: variable tlclass.a2 is mutable. Only const or
immutable class thread local variable are allowed, not tlclass.A

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 10 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714


David Nadlinger <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code klickverbot.at



PST ---
As I mentioned in the pull request, I believe what the error message is
supposed to say is something along the lines of: "Thread-local mutable class
variable cannot be initialized with reference to compile-time constant, use
static constructor instead."

Has been a while since I implemented ClassReferenceExp for LDC, though.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714




2013-12-11 14:52:56 PST ---
OK, but "with reference to compile-time constant" is still not exactly obvious
in its meaning (among other things, it's not clear if what is meant is "with
reference to" or "with _a_ reference to", but either way I think we can still
be clearer).

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714




PST ---


 OK, but "with reference to compile-time constant" is still not exactly obvious
 in its meaning (among other things, it's not clear if what is meant is "with
 reference to" or "with _a_ reference to", but either way I think we can still
 be clearer).


With *a* reference to – I stripped out the articles trying to make the error
message as concise as possible, and missed that it would distort the meaning.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714




2013-12-12 02:18:32 PST ---


 With *a* reference to – I stripped out the articles trying to make the error
 message as concise as possible, and missed that it would distort the meaning.


Easier to use "with a reference to" and "with respect to" respectively, for the
two different cases (just for future reference:-).

What I'm really concerned about, though, is that to me that message is still
pretty much incomprehensible about what it is that I actually did wrong.  Even
when clarified with instructions about what to do to resolve it (initialize to
null or use static this) it's not obvious about what I got wrong or why it's
wrong.

If I understand the logic right, the result of "new MyClass" is not knowable at
compile time --> hence, a compile time constant; but inferring the former
meaning from the latter is not obvious unless one already knows.  Rather than
requiring the programmer's knowledge and understanding to comprehend the error
message, we should aim to use the error message to _increase_ the programmer's
knowledge and understanding.

So, I want an error message that idiots like me can read and go, "Oh! THAT's
why it's wrong," as well as understanding how to fix it. :-)

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 12 2013
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11714




PST ---


 If I understand the logic right, the result of "new MyClass" is not knowable at
 compile time


Actually it is, otherwise you'd get a "cannot be read/evaluated at compile
time" error in the constructor.

The issue here is that in D global variables can only be initialized with
statically known data (written to the relevant sections of the object file).
For everything else, you need to use a static constructor.

While support for converting CTFE class instances into data blobs to write to
an object file was implemented a while ago, variables of a class type are of
course references and need to point somewhere. Now, if a variable is either
immutable or explicitly shared between threads, that's fine, you just emit the
data once and then initialize the variable to point to that. However, for
mutable, thread-local data, this simple scheme doesn't work, as it would
require a new instance to be created for each new thread.

I didn't really think about whether it would be possible to resolve that
situation by emitting all the instance data into the TLS section yet, but this
certainly isn't implemented in DMD right now. Thus, initializing class
references that are (potentially) modified from more than one thread with CTFE
instances is disallowed.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 12 2013