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

           Summary: Result of .stringof is affected by unrelated function
                    declarations
           Product: D
           Version: 1.030
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: clugdbug@yahoo.com.au


--- Comment #0 from Don <clugdbug@yahoo.com.au> 2010-02-12 05:05:31 PST ---
All 3 pragmas should give the same result (except for uint/short/ushort).
But declaring function pointers (dg2 and dg3 below) causes the output to
change.
Related to bug 1424.

===TEST CASE===
void foo(ref uint i) { }
void foo2(ref short i) { }
void foo3(ref ushort i) { }

static if (is(typeof(foo2) P2 == function))
    alias P2 FooParams2;
static if (is(typeof(foo3) P3 == function))
    alias P3 FooParams3;

void function(ref FooParams2) dg2;
void function(ref FooParams3[0]) dg3;

pragma(msg, typeof(&foo).stringof);
pragma(msg, typeof(&foo2).stringof);
pragma(msg, typeof(&foo3).stringof);

---OUTPUT---
void function(ref uint i)
void function(ref (ref short))
void function(ref ushort)
---OUTPUT if comment the lines creating dg2 and dg3---
void function(ref uint i)
void function(ref short i)
void function(ref ushort i)

-- 
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=3796


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> 2010-02-13 00:33:13 PST ---
Types are stored in an associative array indexed by the mangled string for the type. The problem is that there are different ways to have a function type that produces the same mangling - i.e. the arguments can be tuples or not tuples.

The problem shows up when trying to take the pointer to a function type, and different functions have become represented by one of the original function mangled types.

-- 
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=3796



--- Comment #2 from Walter Bright <bugzilla@digitalmars.com> 2010-02-13 00:36:21 PST ---
The problem could be fixed by having .stringof demangle the deco, rather than pretty-printing the type it came from. Unfortunately, there isn't a demangler in the compiler at the moment.

-- 
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=3796


Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de


--- Comment #3 from Rainer Schuetze <r.sagitario@gmx.de> 2010-02-13 01:27:59 PST ---
Here's a test case closely related that's been bugging me:

--- test.d
void foo_a(int a) {}
void foo_b(int b) {}

pragma(msg,"foo_a: " ~ typeof(&foo_a).stringof);
pragma(msg,"foo_b: " ~ typeof(&foo_b).stringof);

--- dmd -c test.d
foo_a: void function(int a)
foo_b: void function(int a)

I'd suggest removing the argument identifiers from the stringof (as the suggestion of converting back the deco would do); it's not part of the type.

Unfortunately this disables some ctfe magic accessing function arguments (but that also badly fails sometimes due to this problem). So some fail-safe way to get the argument identifiers for ctfe would be nice...

-- 
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=3796



--- Comment #4 from Walter Bright <bugzilla@digitalmars.com> 2010-02-13 14:47:25 PST ---
Yes, I think it's pretty clear going the demangler route is better. I agree there should be some other means to get the parameter identifiers.

-- 
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=3796


Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |code@dawg.eu
         Resolution|                            |DUPLICATE


--- Comment #5 from Martin Nowak <code@dawg.eu> 2013-01-16 21:39:05 PST ---
*** This issue has been marked as a duplicate of issue 6902 ***

-- 
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=3796


Andrej Mitrovic <andrej.mitrovich@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrej.mitrovich@gmail.com


--- Comment #6 from Andrej Mitrovic <andrej.mitrovich@gmail.com> 2013-02-08 11:25:51 PST ---
(In reply to comment #2)
> The problem could be fixed by having .stringof demangle the deco, rather than pretty-printing the type it came from. Unfortunately, there isn't a demangler in the compiler at the moment.

This is the code used right now:

/* Bugzilla 3796: this should demangle e->type->deco rather than
* pretty-printing the type.
*/
char *s = e->toChars();

But why not call e->type->toChars()? This would partially fix Issue 9460.

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