Bug 6438 – [CTFE] wrong error "value used before set" when slicing =void array
Status
RESOLVED
Resolution
FIXED
Severity
major
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2011-08-05T03:00:00Z
Last change time
2012-03-19T11:56:36Z
Keywords
CTFE, rejects-valid
Assigned to
yebblies
Creator
dmitry.olsh
Comments
Comment #0 by dmitry.olsh — 2011-08-05T03:00:04Z
void fillWithZero(T)(T[] arr)
{
foreach(ref x; arr)
x = 0;
}
T[4] f(T)()
{
T[4] stackSpace = void;
fillWithZero(stackSpace[]);
return stackSpace;
}
static assert(f!int() == [0,0,0,0]);
Fails with:
bug6XXX.d(11): Error: variable stackSpace is used before initialization
bug6XXX.d(11): Error: cannot evaluate fillWithZero(stackSpace[]) at compile time
bug6XXX.d(16): Error: cannot evaluate f() at compile time
bug6XXX.d(16): Error: static assert (cast(int[])f() == [0,0,0,0]) is not evaluatable at compile time
It's CTFE only issue and is a blocker for one overload of phobos insertInPlace.
Comment #1 by clugdbug — 2011-08-05T23:43:35Z
That's difficult. Implementing this would be a major feature, since assignment from void has a high risk of undefined behaviour.
The f() function is passing a reference to an uninitialized value, to another function. In this particular case, it does initialize every member without reading from any of them, but that's difficult to determine.
I guess it could be implemented by introducing an 'uninitialized expression', but then there are problems with this:
void fillWithZero(T)(T[] arr)
{
auto q = arr[0]; // consider this line
foreach(ref x; arr)
x = 0;
}
T[4] f(T)()
{
T[4] stackSpace = void;
fillWithZero(stackSpace[]);
return stackSpace;
}
static assert(f!int() == [0,0,0,0]);
The assignment to q should generate a 'variable used before set' error. But to be comprehensible, it should also refer to the line where stackSpace was initialized.
Comment #2 by dmitry.olsh — 2011-08-06T09:41:59Z
I see, somehow I hadn't occured to me that it would require a lot of extra work (and storage) to keep track of all uninitialized slots of array.
Apart from variadic overload of insertInPlace I wouldn't expect this pattern to be too common, so it won't be a big issue.
It was propmted by:
insertInPlace(a, x, [b,c]); //allocation here is plain ridiculous
so I proposed a more generalized version that allowed multiple arguments (that also solves this particular problem):
insertInPlace(a, x, b, c); // initializes tmp array with b, c on stack and inserts
Comment #3 by github-bugzilla — 2012-03-19T11:26:46Z