Bug 15481 – GC profiler thinks reducing array.length triggers reallocation

According to spec: "If the new array length is shorter, the array is not reallocated, and no data is copied. It is equivalent to slicing the array". This is contradicted by: void main() { int[] arr; arr.length = 7; arr.length = 6; // not ok -- allocation reported arr = arr[0..5]; // ok -- no allocation } // dmd -profile=gc test.d // (DMD32 D Compiler v2.069.2) // ------------------------------------------------------- // bytes allocated, allocations, type, function, file:line // 28 1 int[] D main test.d:3 // 24 1 int[] D main test.d:4

This is a bug in the GC profiler. The array is not relocated. You can check by comparing the pointers: ---- void main() { int[] arr; arr.length = 7; int* p = arr.ptr; arr.length = 6; assert(arr.ptr == p); /* passes */ } ---- I'm changing the title of this issue accordingly.

Maybe the reallocation function is called and returns the same buffer. But why call it in the first place, if reducing array length is supposed to be _equivalent_ to slicing?

Running the example today yields: bytes allocated, allocations, type, function, file:line 32» 1»int[] D main test.d:3 So this seems to have been fixed by: https://github.com/dlang/druntime/pull/2607