Bug 18637 – [scope][DIP1000] "copying & i into allocated memory escapes a reference to local variable i" where it's inappropriate

Using phobos/dip1000.mak with entry aa[std.exception]=-dip1000 (to be changed from -dip25 to -dip1000) and running (with current, git-cloned dmd/druntime/phobos sources) in directory phobos: make -f posix.mak std/exception.test results in: ... ``` T=`mktemp -d /tmp/.dmd-run-test.XXXXXX` && \ ( \ ../dmd/generated/linux/release/64/dmd -od$T -conf= -I../druntime/import -w -de -dip25 -m64 -fPIC -transition=complex -O -release -dip1000 -main -unittest generated/linux/release/64/libphobos2.a -defaultlib= -debuglib= -L-ldl -cov -run std/exception.d ; \ RET=$? ; rm -rf $T ; exit $RET \ ) std/exception.d(1238): Error: returning & i escapes a reference to local variable i ``` --------------- std/exception.d used to compile successfully with -dip1000 switch until ~ 2018-03-15, failing since. AFAIK, 1. This is @system code, allowed to escape whatever 2. There is no escape (commenting out slicep usages doesn't change the error reported) excerpt from std/exception.d: @system unittest { int i; int[] slice = [0, 1, 2, 3, 4]; int[5] arr = [0, 1, 2, 3, 4]; int*[] slicep = [&i]; <= error line 1238 int*[1] arrp = [&i]; ... assert( slicep[0].doesPointTo(i)); <= slicep usage assert(!slicep .doesPointTo(i)); <= slicep usage ... https://issues.dlang.org/show_bug.cgi?id=17784 is about the wording of this same error msg. Here I claim for this std/exception.d case, that it's a rejects-valid. The comment in phobos/dip1000.mak after aa[std.exception] is outdated, will point to this new bugzilla issue later, but was identifying this same issue. For reference: https://github.com/dlang/phobos/blob/master/std/exception.d

For reference: https://github.com/dlang/phobos/blob/master/dip1000.mak

Since https://github.com/dlang/dmd/commit/ce08cffe71911e86d8adfb241ff4d4e63136db8c the error message is now: std/exception.d(1238): Error: copying & i into allocated memory escapes a reference to local variable i Yes, there is "copying & i into allocated memory", but nothing that makes bad use of it.

Simplifying the test case: void test() { int i; int*[] a = [&i]; // Error: copying `& i` into allocated memory escapes a reference to local variable `i` } This can be worked around with: void test() { int i; int*[] a = [foo(&i)]; } int* foo(int* p) { return p; } It can be reasonably argued either way whether the original test case should be allowed in @system. I'll argue the workaround makes it obvious what one is doing, and unlikely to do it by accident. It's similar to: int* test() { int i; return &i; } being an error even in @system code.