[Issue 11268] Cannot use non-constant CTFE pointer in an initializer

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

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P2  |P3

--

[Issue 11268] Cannot use non-constant CTFE pointer in an initializer

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

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

Dennis  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=20603

--

[Issue 11268] Cannot use non-constant CTFE pointer in an initializer

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

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

Simen Kjaeraas  changed:

   What|Removed |Added

 CC||simon.vanber...@yahoo.de

--- Comment #8 from Simen Kjaeraas  ---
*** Issue 19935 has been marked as a duplicate of this issue. ***

--

[Issue 11268] Cannot use non-constant CTFE pointer in an initializer

[via Digitalmars-d-bugs]

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

Elie Morisse  changed:

   What|Removed |Added

 CC||syniu...@gmail.com

--- Comment #7 from Elie Morisse  ---
Still there:

struct A {
uint d;
}

immutable A abc = { 42 };
immutable(uint)* xyz = 


Error: cannot use non-constant CTFE pointer in an initializer '(42u).d'


I need to initialize a global variable with the address of a global struct
variable member and the workaround to get past that error was to do it in a
static ctor but that's not great since this is inside a template mixin meant to
be used in tons of places.

Although I'm only interested in the address the CTFE interpreter always
"resolves" abc into the literal.

--

[Issue 11268] Cannot use non-constant CTFE pointer in an initializer

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=11268


Don clugd...@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


--- Comment #5 from Don clugd...@yahoo.com.au 2013-10-18 00:25:23 PDT ---
(In reply to comment #4)
 (In reply to comment #3)
  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: ---

[Issue 11268] Cannot use non-constant CTFE pointer in an initializer

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=11268



--- Comment #6 from Jacob Carlborg d...@me.com 2013-10-18 02:32:32 PDT ---
(In reply to comment #3)
 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: ---