The assert in "foo" passes, which it obviously shouldn't. inout(char)[] bar (inout(char)[] a) { return a; } void foo (string str) { string result; result ~= bar(str); assert(result == "!"); } void main () { foo("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"); } If I remove "inout" in "bar" or the append in "foo" the code work as expected. What "result" will actually be depends on the length of the string passed to "foo". I've only tried this with on Mac OS X, both 32 and 64bit.
I have hit this bug with a recent commit to druntime that changes the implementation of AssociativeArray.keys: import std.stdio; void main() { string[] files; files ~= "1"; files ~= "2"; byte[string] cache; cache["3"] = 1; cache["4"] = 1; files ~= cache.keys; writeln(files); } when compiled with -inline, it prints ["1", "2", "\x01\x00"] This seems to be caused by inout(T[]) not being appendable to T[]. Instead it is appended as a single element (_d_arrayappendcT is called, see CatAssignExp::toElem). In case of AssociativeArray.keys, there also seems to be a problem that inlining seems to ignore implicite conversion on the return type by the inlined function.
Yeah, the inliner ends up replacing the call expression with the return expression, but doesn't re-paint the type to account for castless implicit conversions. e2ir uses if/else when it should be using if/elseif/else assert, so it generates wrong code instead of ICEing. https://github.com/D-Programming-Language/dmd/pull/2269
Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ea8e25b2e405a030a16ca6243690d79a8ed6acbd Fix Issue 9356 - -inline with inout and append generates wrong code Force the result expression from inlining a function to match the type of the call expression https://github.com/D-Programming-Language/dmd/commit/566052079a4b9ea1a8b87db2f5a0b22c2ccc7087 Merge pull request #2269 from yebblies/issue9356 Fix Issue 9356 - -inline with inout and append generates wrong code