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 ***