3049 – ICE(cod4.c) or segfault: Array operation on void[] array

Array operations involving void[] can either ICE in the backend, segfault in the front-end, or generate error messages without line numbers, which refer to compiler-generated code. All have the same root cause: such operations are nonsensical.
PATCH(tested on DMD1.045+D2.030): Add this code to the start of BinExp::arrayOp(Scope *) in arrayop.c.
---
	if (type == Type::terror) { return this; }
	if (type->toBasetype()->nextOf()->toBasetype()->ty==Tvoid) {
		error("Cannot perform array operations on void[] arrays");
		return this;
	}
---
// TEST CASE 1: error message with no line number, referring to 
// compiler-generated code. The error is so unhelpful, it might
// as well be an ICE.
// Error: 'p0[p]' is not of arithmetic type, it is a const(void)
// Error: expression -(p0[p]) is void and has no value
void bar(){
 void [] x;
 x[] = -x[];
}
// TEST CASE 2: ICE(backend/cod4.c 353). On D1, it is another 
// error message with no line number
void foo(T)() {
 T[] a;
 a[] = -a[];
}
void main(){
 foo!(void)();
}
// Test case 3: segfault D1 + D2
typedef void car;
void baz(){
 int [] x;
 car [] y;
 y[] = -x[];
}

There was a bug in the patch I posted, it assumed that Type::terror is a unique type whereas it is currently the same as Tint32.
Fortunately, that line was not necessary anyway (it would just result in nicer error messages).
PATCH: Add this code to the start of
BinExp::arrayOp(Scope *) in arrayop.c.
---
 if (type->toBasetype()->nextOf()->toBasetype()->ty==Tvoid) {
 error("Cannot perform array operations on void[] arrays");
 return this;
 }
---

Fixed dmd 1.048 and 2.033