3809 – Struct initializers apparently always CTFE'd

This worked at least as late as 1.051, but now fails in 1.056:
struct S { int xx; int x() { return xx; } }
void foo(S s) {
	S a = {100 / s.x()};
	S b = {100 / s.x()};
}
$ dmd arst.d
Error: divide by 0
arst.d(4): Error: cannot evaluate s.x() at compile time
It seems like it's CTFEing the s.x() calls, which would explain the (bonus: location-lacking) division by zero error as well: xx is zero by default, after all.
Confirmed by changing "int xx" to "int xx = 1" and returning b from foo: the code compiles, and the disassembly shows that no divisions are being performed, it was erroneously done at compile time. Similarly, changing the code to perform e.g. a multiplication instead of a division makes it compile (as the division by zero is the cause for the lack of compilation), but again the s.x() has been improperly CTFE'd.
An additional point of interest: the "cannot evaluate" error is only reported for the S's after the first: with only one, the code compiles (to wrong code, again).

I think this is the same as bug 3792.

Starting with the simple thing: the missing line number in the division by 0 error message.
PATCH: interpret.c, near the start of BinExp::interpretAssignCommon().
 else if (e1->op != TOKslice)
 { /* Look for special case of struct being initialized with 0.
 */
 if (type->toBasetype()->ty == Tstruct && newval->op == TOKint64)
 {
- newval = type->defaultInitLiteral();
+ newval = type->defaultInitLiteral(loc);
 }
 newval = Cast(type, type, newval);
 e = newval;
 }

(In reply to comment #2)
> Starting with the simple thing: the missing line number in the division by 0
> error message.
> PATCH: interpret.c, near the start of BinExp::interpretAssignCommon().
[snip]
Oops, that patch fixed a related test case:
struct S { int xx; }
int badline() { S s; return 100/s.xx; }
static assert(badline());
To fix this one as well, the same patch needs to applied to interpret.c, getVarExp(), around line 1250.
 if (v->init)
 {
 if (v->init->isVoidInitializer())
 {
 error(loc, "variable %s is used before initialization", v->toChars());
 return EXP_CANT_INTERPRET;
 }
 e = v->init->toExpression();
 e = e->interpret(istate);
 }
 else // This should never happen
 {
- e = v->type->defaultInitLiteral();
+ e = v->type->defaultInitLiteral(loc);
 }

This isn't really a regression. Struct static initializers
have always been CTFEd, for example the code below generates a compile-time
div-by-zero error even in DMD 1.023. The only reason this code ever worked
was that CTFE didn't work for member functions. Starting with svn 337 
(DMD1.056), member functions can be called at compile time.
However, the spec says:
"The static initializer syntax can also be used to initialize non-static variables, provided that the member names are not given. 
The initializer need not be evaluatable at compile time."
The compiler has never complied with this part of the spec.
// Should compile, but fails
int bug3809() { asm { nop; } return 0; }
struct BUG3809 { int xx; }
void bug3809b() {
 BUG3809 b = { bug3809() };
}

http://www.dsource.org/projects/dmd/changeset/517 turns it into rejects-valid

Although CTFE is still performed, it's no longer performed incorrectly.
Since CTFE has always been performed on struct initializers, I'm removing the 'regression' tag.

https://github.com/D-Programming-Language/dmd/commit/97c73b140f1cde5d0b713eb72fd1e82084a6ac11
https://github.com/D-Programming-Language/dmd/commit/13dcf90d934325b4f37c50679e07978a821c4249