[Issue 52] ambiguous function pointer silently accepted

Nov 29, 2006

d-bugmail

Nov 29, 2006

d-bugmail

Jan 01, 2007

Feb 25, 2007

Apr 07, 2009

Apr 07, 2009

Apr 07, 2009

Jul 21, 2009

Oct 03, 2009

Jan 05, 2010

http://d.puremagic.com/issues/show_bug.cgi?id=52 wbaxter@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wbaxter@gmail.com ------- Comment #2 from wbaxter@gmail.com 2006-11-28 19:24 ------- Ugh. I just hit this using my flexible signals and slots wrapper. widget.value_changed.fconnect(&other_widget.value); Doh! I really don't want writing a gui to involve gobs of code like: widget.value_changed.fconnect!( typeof(&other_widget.value))(&other_widget.value); Now I really wish I had a tool to find property-like methods in my source code so I can at least make sure they are in the right lexical ordering. :-( Has there been any bug/enhancement filed on this that I can keep a watch on? For my case I'm not even sure what would be the right thing for it to do. What I really need to happen is for fconnect to prefer methods with non-trivial argument lists, but I can't rule out the possibility someone actually wants to connect up a no-argument slot like "updateGui()" to a signal. Maybe we need to be able to optionally specify the arguments when taking a delegates, like: connect(&obj.value(int)); --

http://d.puremagic.com/issues/show_bug.cgi?id=52 ------- Comment #3 from wbaxter@gmail.com 2006-11-28 19:33 ------- (In reply to comment #2) > Has there been any bug/enhancement filed on this that I can keep a watch on? Sorry, obviously this is the bug (I just did a sloppy c&p from newsgroup article digitalmars.com digitalmars.D:44742 ). And if it's not clear what the problem is above, it's that the ''standard D idiom'' to define property methods like: int value() { return m_value; } int value(int v) { return m_value=v; } I use this in Luigi everywhere (http://www.dsource.org/projects/luigi). I also use signals and slots in Luigi. I've got a very handy automatic slot wrapper mechanism that will let you connect any slot with a _compatible_ signature to a signal. The slot doesn't have to have a void return type, for example. This is handy because it lets you connect the 'value' property above directly to the signal (or at least apparently so from the users perspective). --

http://d.puremagic.com/issues/show_bug.cgi?id=52 ------- Comment #4 from thomas-dloop@kuehne.cn 2007-01-01 04:24 ------- test cases: http://dstress.kuehne.cn/nocompile/p/pointer_01_A.d http://dstress.kuehne.cn/nocompile/p/pointer_01_B.d --

http://d.puremagic.com/issues/show_bug.cgi?id=52 smjg@iname.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |benoit@tionex.de ------- Comment #5 from smjg@iname.com 2007-02-25 10:32 ------- *** Bug 1006 has been marked as a duplicate of this bug. *** --

http://d.puremagic.com/issues/show_bug.cgi?id=52 ------- Comment #6 from gide@nwawudu.com 2009-04-07 03:12 ------- The example below does not compile. Has this been fixed? DMD v1.041 bug52.d(11): Error: expected 1 arguments, not 0 bug52.d(26): Error: expected 0 arguments, not 1 DMD v2.027 bug52.d(11): Error: expected 1 function arguments, not 0 bug52.d(20): Error: cannot infer type from overloaded function symbol & fn bug52.d(26): Error: expected 0 arguments, not 1 for non-variadic function type int() --

http://d.puremagic.com/issues/show_bug.cgi?id=52 ------- Comment #7 from gide@nwawudu.com 2009-04-07 05:31 ------- (In reply to comment #6) > The example below does not compile... The example in the issue description does not compile anymore. Has this issue been fixed and is it ok to close this bug? --

http://d.puremagic.com/issues/show_bug.cgi?id=52 ------- Comment #8 from smjg@iname.com 2009-04-07 06:25 ------- No. If you actually read this bug, you'll see that it isn't about lines 11 and 26, but about the fact that ambiguous function pointers are silently accepted. The errors should be at lines 6 and 20. If you take out the lines where errors actually are reported, you'll find that it incorrectly compiles without error (just checked in 1.043). Also, if there are Dstress testcases, please check these before proposing to close a bug. http://www.digitalmars.com/d/archives/digitalmars/D/bugs/bugzilla_usage_tips_10071.html --

July 21, 2009

[Issue 52] ambiguous function pointer silently accepted

Posted by Don

Permalink

Don

Permalink

http://d.puremagic.com/issues/show_bug.cgi?id=52


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|spec                        |patch
                 CC|                            |clugdbug@yahoo.com.au




--- Comment #9 from Don <clugdbug@yahoo.com.au>  2009-07-20 23:58:17 PDT ---

This is fixed in DMD2, and the main part of the code (with error message)
is in the DMD1 source, but not enabled (it won't compile). So it seems Walter
got halfway through fixing this, then got distracted?
(I'm removing 'spec' from the keywords, since it's clear this is just a bug).
Doing a copy-and-paste of the uniqueness test from D2, and disabling the
overload test, it _seems_ to work.
I'm assuming that the 'hasOverloads' member in D2 is for overload sets? In any
case, with this change, the D1 compiler passes the DM test suite, and the
phobos1 unit tests. Of course, if that member isn't for overload sets, this
patch isn't correct, regardless of what the tests say...
(In that case, the code relating to 'hasOverloads' should also be copied from
D2).
----

From D2, in expression.c, in
Type *ExpInitializer::inferType(Scope *sc),
enable the code inside #if DMDV2.
But change the line:
    if (se->hasOverloads && !se->var->isFuncDeclaration()->isUnique())
into:
    if (!se->var->isFuncDeclaration()->isUnique())

And then in func.c, add this code from DMD2.

static int fpunique(void *param, FuncDeclaration *f)
{   FuncDeclaration **pf = (FuncDeclaration **)param;

    if (*pf)
    {    *pf = NULL;
    return 1;        // ambiguous, done
    }
    else
    {    *pf = f;
    return 0;
    }
}

FuncDeclaration *FuncDeclaration::isUnique()
{   FuncDeclaration *result = NULL;

    overloadApply(this, &fpunique, &result);
    return result;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=52 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@digitalmars.com --- Comment #10 from Walter Bright <bugzilla@digitalmars.com> 2009-10-03 02:29:57 PDT --- The hasOverloads needs to be there for it to work right, as if there is a cast it should select the correct overload. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=52 Don <clugdbug@yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Don <clugdbug@yahoo.com.au> 2010-01-05 07:09:05 PST --- This was fixed in DMD1.048 !!! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums