[Issue 17764] [scope][DIP1000] Escape checker defeated by composition transformations

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=17764

ag0aep6g <ag0aep6g at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |ag0aep6g at gmail.com
         Resolution|INVALID                     |---

--- Comment #4 from ag0aep6g <ag0aep6g at gmail.com> ---
(In reply to Walter Bright from comment #3)
> All of them are instances of transitive scope, but scope is not transitive.
> Not compiler bugs.

Reopening.

I don't know if this report shows a problem with `scope` in particular, but it
does show holes in @safe. We can't have a global that points to stack memory in
@safe code.

If @safe works as designed here, you need to revisit the design, because it's
insufficient.

Here's a single example based on use0x5, modified to show more blatantly that
safety is violated:

----
int** global;
immutable int imm;
static this() { imm = 42; }

void main() @safe
{
    f(); /* `global` now points to the stack. Uh-oh. */
    stomp(); /* `*global` now points to `imm`. */
    **global = 13; /* Overwrites `imm`. */
    assert(imm == 42);
        /* Fails. We've (accidentally) mutated an immutable int. */
}

void f() @safe
{
    int* buf;
    static struct Context0x0 { int** str; }
    Context0x0[1] c = Context0x0(&buf);
    global = c[0].str; /* This should be rejected. */
}

void stomp() @safe
{
    immutable int*[4] x = &imm;
}
----

Some of the other variations also seem to boil down to this. Maybe all of them
do.

--