digitalmars.D.bugs - [Issue 2672] New: Delegate .funcptr returns wrong type.
- d-bugmail puremagic.com (53/53) Feb 16 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2672
- d-bugmail puremagic.com (9/9) Mar 01 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2672
- d-bugmail puremagic.com (10/10) Mar 02 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2672
- d-bugmail puremagic.com (9/9) Mar 02 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2672
- d-bugmail puremagic.com (18/18) May 19 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2672
- d-bugmail puremagic.com (12/12) May 20 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2672
- d-bugmail puremagic.com (15/15) Jan 29 2012 http://d.puremagic.com/issues/show_bug.cgi?id=2672
- d-bugmail puremagic.com (10/10) Aug 17 2013 http://d.puremagic.com/issues/show_bug.cgi?id=2672
http://d.puremagic.com/issues/show_bug.cgi?id=2672 Summary: Delegate .funcptr returns wrong type. Product: D Version: 2.025 Platform: PC OS/Version: Windows Status: NEW Keywords: accepts-invalid, ice-on-valid-code, rejects-valid Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: dsimcha yahoo.com 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*) --
Feb 16 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2672 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). --
Mar 01 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2672 ------- 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. --
Mar 02 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2672 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! --
Mar 02 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2672 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 19 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2672 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|ice-on-valid-code | 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
May 20 2009
http://d.puremagic.com/issues/show_bug.cgi?id=2672 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yebblies gmail.com Platform|x86 |All Version|2.025 |D1 & D2 AssignedTo|nobody puremagic.com |yebblies gmail.com OS/Version|Windows |All Severity|normal |major Same sort of thing as issue 3720. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 29 2012
http://d.puremagic.com/issues/show_bug.cgi?id=2672 yebblies <yebblies gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simen.kjaras gmail.com *** Issue 10324 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Aug 17 2013