Thread overview
[Issue 9051] New: [CTFE] Working with non-trivial immutable globals?
Nov 20, 2012
Dmitry Olshansky
[Issue 9051] Passing an immutable global with post-blit to a CTFE function
Nov 21, 2012
Don
Nov 21, 2012
Dmitry Olshansky
Nov 26, 2012
Don
November 20, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9051

           Summary: [CTFE] Working with non-trivial immutable globals?
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: dmitry.olsh@gmail.com


--- Comment #0 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-11-20 12:50:42 PST ---
I'm wondering if this is supposed to work. By all means I don't see why it has
to try this(this) in this case (and moreover fail).

struct Set{
    uint[] arr;
    this(this){  } //comment out to make it compile
}

pure auto getMeASet(uint[] arr)
{
    return Set(arr);
}

immutable set = getMeASet([1,2,3,4]);

pure auto getSecond(in Set set)
{
    return set.arr[1];
}

pragma(msg, getSecond(set));

And the diagnostic spits all kinds of nonsense:

D:\D\ctfe_glob.d(20): Error: variable ctfe_glob.__cpcttmp6 of type struct
const(Set) uses this(this), which is not allowed in static initialization
D:\D\ctfe_glob.d(20):        while evaluating pragma(msg, getSecond((const
const(Set) __cpcttmp6 = Set([1u, 2u, 3u, 4u]);
 , __cpcttmp6)))

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9051


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
            Summary|[CTFE] Working with         |Passing an immutable global
                   |non-trivial immutable       |with post-blit to a CTFE
                   |globals?                    |function


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2012-11-21 02:13:04 PST ---
The error message is not coming from CTFE. Here's a simple case from a comment in the compiler source code (declaration.c):

/* The problem is the following code:
*  struct CopyTest {
*     double x;
*     this(double a) { x = a * 10.0;}
*     this(this) { x += 2.0; }
*  }
*  const CopyTest z = CopyTest(5.3);  // ok
*  const CopyTest w = z;              // not ok, postblit not run
*  static assert(w.x == 55.0);
* because the postblit doesn't get run on the initialization of w.
*/

I think that if we didn't call this(this), wrong code would result.
There is at least a diagnostic bug here - if it must behave this way, the code
that creates the comma expression should be issuing the error.

Interestingly, if you move it inside a function, the result is different:

void foo()
{
   pragma(msg, getSecond(set));
}

qqq.d(19): Error: static variable set cannot be referenced at compile time
qqq.d(19):        called from here: __cpcttmp6.__cpctor(set)
qqq.d(19):        called from here: getSecond((const const(Set) __cpcttmp6 =
__cpcttmp6.__cpctor(set);
 , __cpcttmp6))

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 21, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9051



--- Comment #2 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-11-21 10:49:17 PST ---
(In reply to comment #1)
> The error message is not coming from CTFE. Here's a simple case from a comment in the compiler source code (declaration.c):
> 
> /* The problem is the following code:
> *  struct CopyTest {
> *     double x;
> *     this(double a) { x = a * 10.0;}
> *     this(this) { x += 2.0; }
> *  }
> *  const CopyTest z = CopyTest(5.3);  // ok
> *  const CopyTest w = z;              // not ok, postblit not run
> *  static assert(w.x == 55.0);
> * because the postblit doesn't get run on the initialization of w.
> */
> 
> I think that if we didn't call this(this), wrong code would result.

I agree in general. And But given that getMeASet(uint[] arr) is an r-value. Surely the result of it should be just moved?

The other thought is: can't this(this) be run at compile-time then? What are
limitations?

> There is at least a diagnostic bug here - if it must behave this way, the code that creates the comma expression should be issuing the error.
> 
> Interestingly, if you move it inside a function, the result is different:
> 

The same thing happens if you try passing set by reference be it const or otherwise.

> void foo()
> {
>    pragma(msg, getSecond(set));
> }
> 
> qqq.d(19): Error: static variable set cannot be referenced at compile time
> qqq.d(19):        called from here: __cpcttmp6.__cpctor(set)
> qqq.d(19):        called from here: getSecond((const const(Set) __cpcttmp6 =
> __cpcttmp6.__cpctor(set);
>  , __cpcttmp6))

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
November 26, 2012
http://d.puremagic.com/issues/show_bug.cgi?id=9051



--- Comment #3 from Don <clugdbug@yahoo.com.au> 2012-11-26 00:56:22 PST ---
(In reply to comment #2)
> (In reply to comment #1)
> > The error message is not coming from CTFE. Here's a simple case from a comment in the compiler source code (declaration.c):
> > 
> > /* The problem is the following code:
> > *  struct CopyTest {
> > *     double x;
> > *     this(double a) { x = a * 10.0;}
> > *     this(this) { x += 2.0; }
> > *  }
> > *  const CopyTest z = CopyTest(5.3);  // ok
> > *  const CopyTest w = z;              // not ok, postblit not run
> > *  static assert(w.x == 55.0);
> > * because the postblit doesn't get run on the initialization of w.
> > */
> > 
> > I think that if we didn't call this(this), wrong code would result.
> 
> I agree in general. And But given that getMeASet(uint[] arr) is an r-value. Surely the result of it should be just moved?
> 
> The other thought is: can't this(this) be run at compile-time then? What are
> limitations?

Yeah, that's kind of like bug 7988. The calling of this(this) should be part of the CTFE'd bit. CTFE could cope with it, no problem, it just doesn't get a chance. BTW if we moved the this(this) into CTFE, the example I posted would also work!

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