Fix Issue 9356 - -inline with inout and append generates wrong code #2269
Conversation
| @@ -1332,6 +1332,8 @@ Expression *CallExp::inlineScan(InlineScanState *iss) | |||
| } | |||
| } | |||
|
|
|||
| if (e && type->ty != Tvoid) | |||
| e->type = type; | |||
There was a problem hiding this comment.
Just poking in the dark, but wouldn't this need some CastExp in case there is actually some conversion to do, like int -> long.
There was a problem hiding this comment.
AFAIK those are all added during semantic on the return statement. This problem only occurs for conversions that do not require a cast on the return statement, such as inout -> whatever, which must happen on the caller side.
There was a problem hiding this comment.
Although with that segfault, who knows.
|
Gah, sometimes the CallExp doesn't have a type somehow. |
|
Please rebase. |
…t fit element or array append
Force the result expression from inlining a function to match the type of the call expression
|
Turns out |
…n't had semantic run on them.
|
Updated to remove copy-paste mistake from yebblies@3f9e446#commitcomment-4543998 |
Fix Issue 9356 - -inline with inout and append generates wrong code
|
Thanks. |
|
This change has caused ICE regression 12079. |
Force the result expression from inlining a function to match the type of the call expression.
eg the inlined expression from
inout(char)[] bar (inout(char)[] a) { return a; }called with:
bar("abc")should be
immutable(char)[]but the type of the actual return expression is
inout(char)[].Coupled with an optimistic if/else in e2ir, this generates wrong code.
http://d.puremagic.com/issues/show_bug.cgi?id=9356