www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11268] New: [REG 2.064beta] cannot use non-constant CTFE pointer in an initializer

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

           Summary: [REG 2.064beta] cannot use non-constant CTFE pointer
                    in an initializer
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: doob me.com



This code fails to compile with DMD 2.064 beta:

class OS
{
    static const char[] REBARCLASSNAME = "ReBarWindow32";
}

class CoolBar
{
    static const char* ReBarClass = OS.REBARCLASSNAME.ptr; // line 14
}

Error message:

main.d(14): Error: cannot use non-constant CTFE pointer in an initializer
'"ReBarWindow32"[0]'

The commit that caused this regression is:

43a6c87194cae799650249b10a4f7c910081d280

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11268




Did this actually work correctly before?

Or was it acting as macro, ie was equivalent to:
   static const char* ReBarClass = "ReBarWindow32".ptr;
?

Tests that I've done suggest that it was acting as a macro.
Obviously this should work. But is it actually a regression, or a change from
wrong-code --> rejects-valid ?

In any case it is probably just an over-zealous check in init.c :
hasNonConstPointers().

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 16 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11268






 Did this actually work correctly before?
 
 Or was it acting as macro, ie was equivalent to:
    static const char* ReBarClass = "ReBarWindow32".ptr;
 ?


What do you mean "acting as a macro"?


 Tests that I've done suggest that it was acting as a macro.
 Obviously this should work. But is it actually a regression, or a change from
 wrong-code --> rejects-valid ?


I don't know. All I'm saying is that it used to compile but now it doesn't.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 16 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11268




This isn't a regression. It used to compile, but it generated wrong code.
Here's a reduced case:
---
static const char [] x = "abc";
static const char *p = x.ptr;

void main()
{
   assert(p == x.ptr);
}
---
2.063: compiles, but assert fails
2.064: does not compile.
That's an improvement.

With the way the glue layer works at the moment, I don't think this can be made
to work right now. The glue layer only allows you to have a pointer to a
symbol, but this is a pointer to a nameless string literal. It could never have
generated correct code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 16 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11268


Luís Marques <luis luismarques.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luis luismarques.eu



---


 This isn't a regression. It used to compile, but it generated wrong code.


This also used to compile and fail the assert:

    const foo = "foo";
    const(char)* p = foo.ptr;

    void main()
    {
        assert(p == foo.ptr);
    }

(although I did not rely on that behavior, so for me this was a regression)

But if you change to:

    const foo = "foo";
    const(char)* p = foo; // remove .ptr

    void main()
    {
        assert(p == foo.ptr);
    }

It still compiles with git head, and fails the assert.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 16 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11268


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
            Summary|[REG 2.064beta] cannot use  |Cannot use non-constant
                   |non-constant CTFE pointer   |CTFE pointer in an
                   |in an initializer           |initializer
           Severity|regression                  |normal







 This isn't a regression. It used to compile, but it generated wrong code.


 
 This also used to compile and fail the assert:
 
     const foo = "foo";
     const(char)* p = foo.ptr;
 
     void main()
     {
         assert(p == foo.ptr);
     }
 
 (although I did not rely on that behavior, so for me this was a regression)


The compiler was still generating wrong code.
I'm downgrading this bug from regression to rejects-valid, since AFAIK there
were no cases where the compiler generated correct code.

Sometimes there are "regressions" where something no longer compiles that was
previously wrong, but happened to work in a few special cases. But this doesn't
even seem to be one of those issues. It was always wrong.


 But if you change to:
 
     const foo = "foo";
     const(char)* p = foo; // remove .ptr
 
     void main()
     {
         assert(p == foo.ptr);
     }
 
 It still compiles with git head, and fails the assert.


Interesting. I'm not sure if that's a bug, or not. It's a slightly different
case though.
It's treating "foo" as a rvalue, not an lvalue. It evaluates foo, and the
implicit conversion to char * happens afterwards. But with ".ptr" it _has_ to
treat foo as an lvalue. while evaluating it. So the order of evaluation is
different.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 18 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11268






 This isn't a regression. It used to compile, but it generated wrong code.
 Here's a reduced case:
 ---
 static const char [] x = "abc";
 static const char *p = x.ptr;
 
 void main()
 {
    assert(p == x.ptr);
 }
 ---


I think the original code only wanted a char* with the content "ReBarWindow32"
at compile time.

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