digitalmars.D - Current limitations of -dip1000
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (77/77) Oct 09 2017 I'm trying to figure out how to make my manually written
- Walter Bright (17/20) Oct 09 2017 I find it is hopeless to explain how this works with refs, arrays, membe...
- meppl (40/45) Oct 10 2017 this looks like an issue to me. If its a template the pointer can
- meppl (26/27) Oct 10 2017 also, these differ:
- 12345swordy (3/30) Oct 10 2017 Report any bugs to the official bug tracker here:
- =?UTF-8?B?Tm9yZGzDtnc=?= (2/4) Oct 10 2017 Shall I file the bug?
- =?UTF-8?B?Tm9yZGzDtnc=?= (2/6) Oct 10 2017 I did it: https://issues.dlang.org/show_bug.cgi?id=17892
- Walter Bright (2/3) Oct 10 2017 Thank you!
- Per =?UTF-8?B?Tm9yZGzDtnc=?= (3/4) Oct 11 2017 You're very welcome!
I'm trying to figure out how to make my manually written containers have scope-aware element(s)-accessing functions. I've come up with 5 different situations as follows safe pure nothrow nogc: struct S(T) { static private struct Range { S!T* _parent; } scope inout(Range) range() inout return { return typeof(return)(&this); } scope inout(T)[] opSlice() inout return { return x[]; } scope inout(T)[] slice() inout return { return x[]; } scope ref inout(T) front() inout return { return x[0]; } scope inout(T)* pointer() inout return { return &x[0]; } T[128] x; } /// this correctly fails int[] testOpSlice() { S!int s; return s[]; // errors with -dip1000 } /// this correctly fails int[] testSlice() { S!int s; return s.slice; // errors with -dip1000 } /// this correctly fails auto testRange() { S!int s; return s.range; // errors with -dip1000 } /// TODO this should fail ref int testFront() { S!int s; return s.front; // should error with -dip1000 } /// TODO this should fail int* testPointer() { S!int s; return s.pointer; // should error with -dip1000 } Compiling this with dmd version 2.076.0-b1 along with -dip25 and -dip1000 flags gives three errors: test_scope.d(42,13): Error: returning `s.opSlice()` escapes a reference to local variable `s` test_scope.d(49,12): Error: returning `s.slice()` escapes a reference to local variable `s` test_scope.d(56,12): Error: returning `s.range()` escapes a reference to local variable `s` It's very nice that the scope-analysis figures out that even the `range` member function contains an escaping pointer to the owning struct. However, the other two `testFront` and `testPointer` don't error. Why are these two simpler cases allowed to escape a scoped reference and pointer which both outlive the lifetime of the owning struct `S`?
Oct 09 2017
On 10/9/2017 8:04 AM, Per Nordlöw wrote:I'm trying to figure out how to make my manually written containers have scope-aware element(s)-accessing functions. I've come up with 5 different situations as followsI find it is hopeless to explain how this works with refs, arrays, member functions, etc. It's much simpler to rewrite anything you're unsure of as using nothing but pointers and free functions. (After all, the compiler lowers all that reference stuff to pointers and free functions anyway.) Making it explicit where all the pointers and parameters are makes it a LOT easier to reason about how dip1000 works. For example, replace: int[] a[0] with: int* *a Get rid of the templates, too. Replace T with int. Get rid of any of the layers of confusing complexity. Think "what does the compiler lower this construct to" and do that. Once it is clear how the pointers works, then start adding the complexity back in.
Oct 09 2017
On Tuesday, 10 October 2017 at 02:37:21 UTC, Walter Bright wrote:On 10/9/2017 8:04 AM, Per Nordlöw wrote:this looks like an issue to me. If its a template the pointer can escape. The non-template-version doesnt let the pointer escape safe: struct ST( T) { safe: T[ 128] x; scope ref T front() return { return x[ 0]; } scope T* pointer() return { return &x[ 0]; } } ref int testFrontT() { ST!int s; return s.front(); // pointer escapes } int* testPointerT() { ST!int s; return s.pointer(); // pointer escapes } struct S { safe: int[ 128] x; scope ref int front() return { return x[ 0]; } scope int* pointer() return { return &x[ 0]; } } ref int testFront() { S s; return s.front(); // error } int* testPointer() { S s; return s.pointer(); // error }...Get rid of the templates, too. Replace T with int. Get rid of any of the layers of confusing complexity. ...
Oct 10 2017
On Tuesday, 10 October 2017 at 09:55:13 UTC, meppl wrote:...also, these differ: (with dmd v2.076.0) safe: struct S { safe: int* x; scope int* pointer() return { return x; } } int* testPointer() { S s; return s.pointer(); // no error } struct SA { safe: int[ 128] x; scope int* pointer() return { return &x[ 0]; } } int* testPointerA() { SA s; return s.pointer(); // error }
Oct 10 2017
On Tuesday, 10 October 2017 at 10:49:54 UTC, meppl wrote:On Tuesday, 10 October 2017 at 09:55:13 UTC, meppl wrote:Report any bugs to the official bug tracker here: https://issues.dlang.org/...also, these differ: (with dmd v2.076.0) safe: struct S { safe: int* x; scope int* pointer() return { return x; } } int* testPointer() { S s; return s.pointer(); // no error } struct SA { safe: int[ 128] x; scope int* pointer() return { return &x[ 0]; } } int* testPointerA() { SA s; return s.pointer(); // error }
Oct 10 2017
On Tuesday, 10 October 2017 at 14:12:04 UTC, 12345swordy wrote:Report any bugs to the official bug tracker here: https://issues.dlang.org/Shall I file the bug?
Oct 10 2017
On Tuesday, 10 October 2017 at 18:58:42 UTC, Nordlöw wrote:On Tuesday, 10 October 2017 at 14:12:04 UTC, 12345swordy wrote:I did it: https://issues.dlang.org/show_bug.cgi?id=17892Report any bugs to the official bug tracker here: https://issues.dlang.org/Shall I file the bug?
Oct 10 2017
On 10/10/2017 3:31 PM, Nordlöw wrote:I did it: https://issues.dlang.org/show_bug.cgi?id=17892Thank you!
Oct 10 2017
On Wednesday, 11 October 2017 at 03:32:41 UTC, Walter Bright wrote:Thank you!You're very welcome!
Oct 11 2017