Bug 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