[Issue 11268] Cannot use non-constant CTFE pointer in an initializer
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
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
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
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 = &abc.d;
Error: cannot use non-constant CTFE pointer in an initializer '&A(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
http://d.puremagic.com/issues/show_bug.cgi?id=11268
--- Comment #6 from Jacob Carlborg 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: ---
[Issue 11268] Cannot use non-constant CTFE pointer in an initializer
http://d.puremagic.com/issues/show_bug.cgi?id=11268
Don 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 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: ---
