D-ark corners - algorithms, ranges, and auto ref - best practices guides.

[aliak]

On Tuesday, 23 July 2019 at 15:22:37 UTC, ag0aep6g wrote:
> On 23.07.19 15:51, aliak wrote:
>> Hi, I recently ran in to a problem with stack corruption [0].
> [...]
>> Anyway, this is what I narrowed it down to eventually in 
>> client code.
>> 
>> @safe:
>> auto foundValue = makeRange("one")
>>    .algorithm;
>> useValue(foundValue); // BOOM
> [...]
>> And finally, I've been keeping note of various gotchas in D, 
>> and traps, etc [1] and I'm wondering if anyone else takes note 
>> of these things? Can you post links to them here if you do?
> [...]
>> [0]: 
>> https://forum.dlang.org/thread/hhxabgmrwvqvmezezyym@forum.dlang.org
>> [1]: https://github.com/aliak00/d-isms/tree/master/da-faq
>
> If that code leads to memory corruption, it shouldn't compile 
> as @safe. You're looking at a compiler bug, not a gotcha.
>
> Might already be filed here:
> https://issues.dlang.org/show_bug.cgi?id=17927

Hmm, if the spec is not wrong, and return should be inferred, 
then could it be an ldc bug? If you run this with the llvm 
sanitizer (on my system at least) you'll get an ASAN stack 
corruption assert with details.

import std;

struct W(T) {
     T value;
     ref inout(T) front() inout { return value; }
}

auto ref get(T)(W!T value) {
     return value.front;
}

struct S {
     string a;
}

void main() @safe {
     S[] arr;
     arr ~= W!S(S("one")).get;
     writeln(arr[0]);
}

Compiler/run with: ldc2 -fsanitize=address -g -disable-fp-elim 
temp.d && ./temp

But then again, I have no idea if the dmd version is passing "by 
luck" or if for some reason dmd properly infers it as return ref 
and somehow ldc messes that up.