<div dir="ltr"><div><div><div><div><div>There's a rather sour test in the testsuite (runnable/test42.d : test7290) that looks at the address of the object, and infers locality based on the value of the address.<br><br>
This is very problematic and doesn't actually reliably test the feature, as it makes big assumptions about the behaviour of what the compiler does.  Such as:<br><br>a) No functions are inlined.<br>b) There isn't any optimisations in place that omit the frame pointer from the function.<br>
</div><div>c) The compiler pushes the objects on the stack in a deterministic order when building under optimisations.<br> <br></div>There needs to be a better defined test for this as the current one is extremely implementation specific and fragile.<br>
<br></div>Only thought that immediately comes to mind other than pulling the test out of the testsuite is to overload _d_allocmemory to ensure that it is never called.<br><br><br></div>eg:<br><br></div>void* _d_allocmemory (size_t sz)<br>
{<br></div>  assert(false);<br><div>}<br><div><div><div><div><div><div><br></div><div>void test7290()<br>{<br></div><div>  int add = 2;<br></div><div>  scope sdg = (int a) => a + add;  // OK, is a stack allocation.<br>
</div><div>  auto hdg = (int a) => a + add;  // Fails as _d_allocmemory is called to initialise closure.<br></div><div>}<br></div><div><br><br></div><div>Though this would break test54 in that same file (would need to move it out).<br>
</div><div><br></div><div>Thoughts?<br><br></div><div><br></div><div>Regards<br></div><div>-- <br>Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';
</div></div></div></div></div></div></div></div>