Fix __cmp(void[], void[])

[kinke]

The testcase dies with an access violation with DMD 2.074 on Windows:

object.Error@(0): Access Violation
----------------
0x0041C60D in memcmp
0x00402263 in pure nothrow @nogc @safe int object.__cmp!(void, const(void)).__cmp(void[], const(void)[]) at C:\LDC\dmd2\windows\bin\..\..\src\druntime\import\object.d(3407)
0x004021F7 in _Dmain at C:\LDC\ninja-ldc\..\current.d(27)

[PetarKirov]

I think that (T[] a, U[] b) => a == b, (T[] a, U[] b) => a < b and friends should be disallowed if either is(Unqual!T == void) or is(Unqual!U == void) and allow only a is b.

[PetarKirov]

And if bitwise comparison is desired, the arrays should be casted to const(ubyte)[].

[kinke]

I don't have a strong opinion on a < b for void[] arrays, but I'm very much against disabling the (in)equality check. I'm under the impression that void[] is used quite often, to describe an untyped range of memory, so having to cast all of these manually when checking for (in)equality seems damn ugly and inconvenient to me. (edit: yep, that should be fine via is).

Much more importantly, the front-end should make sure bugs like these can't occur (and the DMD backend hardened in this regard). The nested function indexes the void[] array, returns a void by ref (!), the test takes the (apparently invalid) address of the returned void reference and forwards it to memcmp...
Indexing a void[] array could be useful to obtain addresses (&slice[2], but that can be done more cleanly via slice.ptr + 2), but a function returning ref void and taking the address of a void value is... definitely strange. :]
If returning a ubyte when indexing a void[] array is deemed too strange, I'd be in favor of just prohibiting it (slicing obviously still allowed).

[PetarKirov]

CC @andralex @WalterBright

[MartinNowak]

hx for the fix
Filed the ref void-return as Issue 17447 – ref void return should be an error

[kinke]

Thanks Martin.