Illegal hardware instruction instead of RangeError

[Geod24]

void main ()
{
    int[] arr = new int[](42);
    int[] arr2 = new int[](200);
    arr[] = arr2;
}

Tried on OSX with v1.26.0 (from Homebrew) and v1.27.0-beta3 (from install.sh) and on Ubuntu 18.04 with v1.20.1 and got an "Illegal hardware instruction" every time.

[kinke]

That's (most likely) an assert(0) in release druntime's enforceRawArraysConformable() called by LDC-specific _d_array_slice_copy (see https://github.com/ldc-developers/ldc/issues/2425 for some context). You can use -link-defaultlib-debug for the proper msg; a proper way to tackle this IMO is to make the frontend lower these copies to a druntime template, similar to core.internal.array.equality.__equals for comparisons.

[Geod24]

Thanks, we're already using -link-defaultlib-debug for UT, but not in our deployed build.

a proper way to tackle this IMO is to make the frontend lower these copies to a druntime template

IIUC from the other issue, it's because of -betterC, right ? It's a bit of a shame that betterC would make regular D experience's worse though.

[kinke]

IIUC from the other issue, it's because of -betterC, right ?

Nope, it's because we, iff assertions are enabled, don't emit a slice copy (check for matching lengths & non-overlap + memcpy) directly in the backend like DMD, but use a druntime function (simpler and IMO more elegant). It's non-templated and thus a problem for betterC.

[kinke]

Note that enforceRawArraysConformable() is used for more druntime hooks, like _d_arraycopy, _darrayassign{l,r} and _d_array_ctor. So making that consistent with DMD's inline code throwing a RangeError or whatever would probably make sense (upstream).

Here's one variant of DMD inline code generation for this check: https://github.com/dlang/dmd/blob/49785914928007a779efe45e1de3b7af2ee52ca7/src/dmd/e2ir.d#L2249-L2269