Bug 10336 – Inconsistent call strategy and function behavior in member template opDispatch map to function delegate

Status
RESOLVED
Resolution
DUPLICATE
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-06-11T10:09:00Z
Last change time
2013-11-18T17:56:25Z
Assigned to
nobody
Creator
d+bugzilla

Comments

Comment #0 by d+bugzilla — 2013-06-11T10:09:55Z
DMD 2.063 Code: struct test { template opDispatch(string name) { enum opDispatch = function(int x) { return x; }; } } int main() { test t; return t.hello(12); } Output is consistently 0.
Comment #1 by d+bugzilla — 2013-06-11T12:20:03Z
(In reply to comment #0) > DMD 2.063 > > Code: > > struct test { > template opDispatch(string name) { > enum opDispatch = function(int x) { > return x; > }; > } > } > > int main() { > test t; > > return t.hello(12); > } > > Output is consistently 0. It appears that the caller is treating the method as a regular/static function, while the function itself is behaving as a method. This is perhaps more evident through the following D code and the corresponding (non-optimized) generated code: struct test { int member = 32; template opDispatch(string name) { enum opDispatch = function(int x) { return x + member; }; } } int main() { test t; return t.hello(12); } (OK) Expects EAX to point to an instance of test, with parameters pushed to stack: pure nothrow @safe int test.test.opDispatch!("hello").__funcliteral1(int): push EBP mov EBP,ESP sub ESP,4 mov EAX,[EAX] add EAX,8[EBP] leave ret 4 nop (ERROR) Disregards it is dealing with a method call: _Dmain: push EBP mov EBP,ESP mov EAX,_D4test4test6__initZ@SYM32 ; what? mov EAX,0Ch call pure nothrow @safe int test.test.opDispatch!("hello").__funcliteral1(int)@PC32 pop EBP ret Expected: _Dmain: push EBP mov EBP,ESP ; <begin missing> sub ESP,4 mov EAX,_D4test4test6__initZ@SYM32 mov -4[EBP],EAX push 0Ch lea EAX,-4[EBP] ; <end missing> call pure nothrow @safe int test.test.opDispatch!("hello").__funcliteral1(int)@PC32 leave ret
Comment #2 by d+bugzilla — 2013-11-18T17:56:25Z
*** This issue has been marked as a duplicate of issue 11545 ***