digitalmars.D.bugs - [Issue 3796] New: Result of .stringof is affected by unrelated function declarations
- d-bugmail puremagic.com (42/42) Feb 12 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3796
- d-bugmail puremagic.com (15/15) Feb 13 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3796
- d-bugmail puremagic.com (8/8) Feb 13 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3796
- d-bugmail puremagic.com (23/23) Feb 13 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3796
- d-bugmail puremagic.com (7/7) Feb 13 2010 http://d.puremagic.com/issues/show_bug.cgi?id=3796
- d-bugmail puremagic.com (12/12) Jan 16 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3796
- d-bugmail puremagic.com (16/19) Feb 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=3796
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
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: -------
Feb 12 2010
d-bugmail puremagic.com
http://d.puremagic.com/issues/show_bug.cgi?id=3796
Walter Bright <bugzilla digitalmars.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla digitalmars.com
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: -------
Feb 13 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3796 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: -------
Feb 13 2010
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
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: -------
Feb 13 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3796 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: -------
Feb 13 2010
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
*** 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: -------
Jan 16 2013
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
11:25:51 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.
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: -------
Feb 08 2013