www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3131] New: better type resolve

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3131

           Summary: better type resolve
           Product: D
           Version: 2.028
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: davidl 126.com


class c{
}

c c;
c = new c;

Jarrett mentioned that it doesn't compile in bug 3125.

This can alleviate the pain of porting C# code.
I patched this in my own box when I tried to port some C# code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 03 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3131


Jarrett Billingsley <jarrett.billingsley gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jarrett.billingsley gmail.c
                   |                            |om




--- Comment #1 from Jarrett Billingsley <jarrett.billingsley gmail.com> 
2009-07-03 08:42:11 PDT ---
No.  This is working as intended.  What you're doing here is shadowing the
global 'c' with a local 'c'.  Symbol lookup in D is simple: it looks in
enclosing scopes until it finds a symbol of the given name, no matter how
you're using that name.  If you're porting code from another language, you're
going to have to expect some translation work.  And besides, what's so
difficult about "c c = new c;", or better yet, _not doing it in the first
place_?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3131


Jarrett Billingsley <jarrett.billingsley gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement




-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3131





--- Comment #2 from david <davidl 126.com>  2009-07-03 16:33:30 PDT ---
(In reply to comment #1)
 No.  This is working as intended.  What you're doing here is shadowing the
 global 'c' with a local 'c'.  Symbol lookup in D is simple: it looks in
 enclosing scopes until it finds a symbol of the given name, no matter how
 you're using that name.  If you're porting code from another language, you're
 going to have to expect some translation work.  And besides, what's so
 difficult about "c c = new c;", or better yet, _not doing it in the first
 place_?

c c = new c; <-- this is the only 1 case that trigger this issue. Sometimes you can have class ClassType1 { } class ClassType2 { ClassType1 ClassType1; void func(ClassType1 t){} // this ClassType1 is clearly referring to the type of "ClassType1" } And it's not hard to make this work. I see no reason to ignore this one. My own dmd gets several other features patched. So it's somewhat troublesome to isolate the patch to this particular bug. The idea is pretty simple, when you try to tell the user the error, firstly try to resolve the type upper scope A roughly patch: Type *TypeIdentifier::semantic(Loc loc, Scope *sc) { Type *t; Expression *e; Dsymbol *s; +++ bool tried = false; +++ Scope *sce = sc -> enclosing; //printf("TypeIdentifier::semantic(%s)\n", toChars()); resolve(loc, sc, &e, &t, &s); +++ L1: if (t) { //printf("\tit's a type %d, %s, %s\n", t->ty, t->toChars(), t->deco); if (t->ty == Ttypedef) { TypeTypedef *tt = (TypeTypedef *)t; if (tt->sym->sem == 1) error(loc, "circular reference of typedef %s", tt->toChars()); } t = t->addMod(mod); } else { +++ if ( sce != NULL) +++ { +++ resolve(loc, sce, &e, &t, &s); +++ sce = sce -> enclosing; +++ goto L1; +++ } #ifdef DEBUG if (!global.gag) printf("1: "); #endif if (s) { s->error(loc, "is used as a type"); //halt(); } else error(loc, "%s is used as a type", toChars()); t = tvoid; } //t->print(); return t; } You see, it's simple. I think it should be enhanced. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3131





--- Comment #3 from david <davidl 126.com>  2009-07-03 16:43:39 PDT ---
Umm, this time I review the patch, that bool tried is some legacy way to solve
the issue. It didn't work correctly if it requires to resolve the symbol in
upper-upper scope. I changed it to the current one, but the bool tried left
forgotten. 

I won't try to hack the compiler, if hacking it is relatively simple, the issue
is hard to bypass. The original C# code uses duplication name of var and type
everywhere.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3131





--- Comment #4 from Jarrett Billingsley <jarrett.billingsley gmail.com> 
2009-07-03 16:59:11 PDT ---
(In reply to comment #2)

 Sometimes you can have
 
 class ClassType1
 {
 }
 
 class ClassType2
 {
   ClassType1 ClassType1;
   void func(ClassType1 t){} // this ClassType1 is clearly referring to the type
 of "ClassType1"
 }
 
 And it's not hard to make this work. I see no reason to ignore this one.

I do. It's stupid and pointless. Just name your local variable _something else_.
 You see, it's simple. I think it should be enhanced.

Just because it's simple doesn't mean it should be done. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3131


Derek Parnell <ddparnell bigpond.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ddparnell bigpond.com




--- Comment #5 from Derek Parnell <ddparnell bigpond.com>  2009-07-03 20:33:36
PDT ---
Regardless of whether it is a good idea or not, I see a related problem in that
there is a bit of apparent inconsistency.

Look at this program ...

// ------------
struct X 
{
}
struct Y
{
    X X;   // Disallowed
}
void main()
{
    X X;   // Allowed.
}
// ------------

Either both instances should be disallowed or both allowed, IMO.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 03 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3131





--- Comment #6 from Jarrett Billingsley <jarrett.billingsley gmail.com> 
2009-07-03 21:43:33 PDT ---
(In reply to comment #5)
 Regardless of whether it is a good idea or not, I see a related problem in that
 there is a bit of apparent inconsistency.
 
 Look at this program ...
 
 // ------------
 struct X 
 {
 }
 struct Y
 {
     X X;   // Disallowed
 }
 void main()
 {
     X X;   // Allowed.
 }
 // ------------
 
 Either both instances should be disallowed or both allowed, IMO.

I would say they should both be allowed. The declaration of the struct member should happen semantically after the type lookup, just like with the variable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 03 2009