The type of the function pointer returned by delegate.funptr appears to have the same parameter list as the corresponding delegate. This is incorrect, since a function pointer in this form is useless for actually calling the function in question. The type of the function pointer should have the pointer to whatever context is relevant added to its parameter list.
import std.stdio;
struct Foo {
uint function() myFunPtr;
uint i;
uint myFun() {
return i * 2;
}
}
void main() {
Foo foo;
foo.i = 2;
auto someDelegate = &(foo.myFun);
foo.myFunPtr = someDelegate.funcptr; // Works. Shouldn't.
// Should be uint function(foo*). Is uint function().
writeln(typeof(someDelegate.funcptr).stringof);
/* Without this line of code, DMD outputs the assembly such that foo's this
* pointer just happens to be in EAX. This causes things to work, since
* DMD passes the this pointer in EAX. This line makes sure something else
* gets written to EAX.*/
uint fooRet = fooPtr();
// Of course, this doesn't work because no this pointer is getting
// passed in.
writeln(foo.myFunPtr());
}
auto fooPtr = &foo; // Make call indirect so it can't be inlined.
uint foo() {
return 1;
}
Also, the correct version of this code is rejected. If I change the type of Foo.myFunPtr to uint function(Foo*), I receive the following errors:
Assertion failure: 'tn->mod & MODinvariant || tn->mod & MODconst' on line 740 in file 'mtype.c'
test7.d(17): Error: cannot implicitly convert expression (*((& someDelegate+4))) of type uint function() to uint function(Foo*)
Comment #1 by dsimcha — 2009-03-01T19:44:54Z
Sane version of this bug report, not posted ridiculously late at night (don't know what I was thinking on my initial post):
void delegate(uint) foo;
pragma(msg, typeof(foo.funcptr).stringof); // void function(uint)
Because of this, you can't use foo.funcptr for calling the underlying function. The correct type would be void function(void*, uint).
Comment #2 by kamm-removethis — 2009-03-02T05:43:33Z
Not every delegate can be called as a function. Consider a delegate with the signature 'Struct delegate(int)' whose parameters get passed as a1, hidden, this. If you cast its funcptr to 'Struct function(int a1, void* fthis)' the arguments will be passed as a1, fthis, hidden.
Delegates that don't use hidden can be represented as a function with the this pointer as the last argument.
I'd argue that funcptr shouldn't have a function type at all.
Comment #3 by tomas — 2009-03-02T08:48:16Z
I still think it's silly to throw away function/delegate type compatibility just for the reason of defining parameter passing order at some point in the future. I already posted on the NG about this quite a while back, but my opinion stands!
ABI compatibility should be a good thing, in these cases, it's a stick in the wheel!
Comment #4 by clugdbug — 2009-05-19T00:35:27Z
Simple test case for the ICE:
-----
auto x = &bar;
int bar() { return 1;}
int function() y = null;
-----
Curiously, it's crashing on the assignment to y! It doesn't happen if you move y above x. Something in the declaration of x is corrupting a data structure (it's related to MODinvariant). I'm still tracking it down.
Comment #5 by clugdbug — 2009-05-20T02:18:16Z
I have created bug 3010 to cover the two Internal Compiler Errors mentioned in the comments, since it's a completely unrelated issue. I'm therefore removing ice-on-valid-code from this bug.
Comment #6 by yebblies — 2012-01-29T22:17:26Z
Same sort of thing as issue 3720.
Comment #7 by yebblies — 2013-08-17T23:15:59Z
*** Issue 10324 has been marked as a duplicate of this issue. ***
Comment #8 by simen.kjaras — 2020-08-27T08:37:13Z
*** Issue 21195 has been marked as a duplicate of this issue. ***
Comment #9 by robert.schadek — 2024-12-13T17:49:25Z