www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 249] New: circular typedef and alias bugs

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

           Summary: circular typedef and alias bugs
           Product: D
           Version: 0.162
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid, diagnostic, ice-on-invalid-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: jpelcis gmail.com


Here are a few closely related bugs with circular typedefs and aliases.  The
most important one is the first (it crashes the compiler), but each version has
the same problem but a different error message.

-------------------------------

module test1;

typedef foo bar;
typedef bar foo;

void main () {
        foo blah;
}

C:\programs>dmd test1.d -v
parse     test1
semantic  test1
semantic2 test1
semantic3 test1
Stack overflow


Without an error message, this can be almost impossible to track down.

-------------------------------

module test2;

typedef foo bar;
alias bar foo;

void main () {
        foo blah;
}

C:\programs>dmd test2.d
test2.d(3): circular reference of typedef bar
test2.d(3): circular reference of typedef bar


Interesting way to phrase the error message.  It also appears twice, but only
shows one of the line numbers.

-------------------------------

module test3;

alias foo bar;
typedef bar foo;

void main () {
        foo blah;
}

C:\programs>dmd test3.d
test3.d(4): circular reference of typedef foo


This error message is similar to the last one, but it only shows up once this
time.  Is it really still a typedef though, or is it an alias?  Either way, one
is wrong.

-------------------------------

module test4;

alias foo bar;
alias bar foo;

void main () {
        foo blah;
}

C:\programs>dmd test4.d
test4.d(4): alias test4.foo recursive alias declaration


I think the "circular" from the other error messages is better than
"recursive."  Also, it still only has one of the line numbers and for some
reason is the only one that keeps the module name.


--
Jul 10 2006
next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
d-bugmail puremagic.com wrote:

 Here are a few closely related bugs with circular typedefs and aliases.  The
 most important one is the first (it crashes the compiler), but each version has
 the same problem but a different error message.
 
 -------------------------------
 
 module test1;
 
 typedef foo bar;
 typedef bar foo;
 
 void main () {
         foo blah;
 }
 
 C:\programs>dmd test1.d -v
 parse     test1
 semantic  test1
 semantic2 test1
 semantic3 test1
 Stack overflow
 
 
 Without an error message, this can be almost impossible to track down.


Yes, that is a bug.


 -------------------------------
 
 module test2;
 
 typedef foo bar;
 alias bar foo;
 
 void main () {
         foo blah;
 }
 
 C:\programs>dmd test2.d
 test2.d(3): circular reference of typedef bar
 test2.d(3): circular reference of typedef bar
 
 
 Interesting way to phrase the error message.  It also appears twice, but only
 shows one of the line numbers.


Generally, the compiler tries to invent a fix to continue on from a 
syntax error, but often those fixes just result in more error messages. 
Not great, but not really a bug.


 -------------------------------
 
 module test3;
 
 alias foo bar;
 typedef bar foo;
 
 void main () {
         foo blah;
 }
 
 C:\programs>dmd test3.d
 test3.d(4): circular reference of typedef foo
 
 
 This error message is similar to the last one, but it only shows up once this
 time.  Is it really still a typedef though, or is it an alias?  Either way, one
 is wrong.


I'm not sure why the message is wrong. The code certainly is.


 
 -------------------------------
 
 module test4;
 
 alias foo bar;
 alias bar foo;
 
 void main () {
         foo blah;
 }
 
 C:\programs>dmd test4.d
 test4.d(4): alias test4.foo recursive alias declaration
 
 
 I think the "circular" from the other error messages is better than
 "recursive."  Also, it still only has one of the line numbers and for some
 reason is the only one that keeps the module name.


It's still a reasonable error message - I agree it could be improved, 
but why is it a bug?
Jul 10 2006
parent reply James Pelcis <jpelcis gmail.com> writes:
Walter Bright wrote:

 d-bugmail puremagic.com wrote:

 test2.d(3): circular reference of typedef bar
 test2.d(3): circular reference of typedef bar

  snip

 test3.d(4): circular reference of typedef foo


 
 I'm not sure why the message is wrong. The code certainly is.


I agree that the code is wrong.  However, one of those is an alias and 
the other is a typedef.  I suppose it could be debated which is which, 
but only one is a typedef.


 It's still a reasonable error message - I agree it could be improved, 
 but why is it a bug?


I think that the error messages are good, even if they aren't perfect. 
My point is that those four pieces of code are essentially the same but 
all four produce different error messages.  Could they all be made the same?
Jul 10 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
James Pelcis wrote:

 I think that the error messages are good, even if they aren't perfect. 
 My point is that those four pieces of code are essentially the same but 
 all four produce different error messages.  Could they all be made the 
 same?


I like to keep error messages generated by different parts of the 
compiler slightly different - makes it easier to track them down.
Jul 10 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Tue, 11 Jul 2006 15:53:11 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 James Pelcis wrote:

 I think that the error messages are good, even if they aren't perfect.  
 My point is that those four pieces of code are essentially the same but  
 all four produce different error messages.  Could they all be made the  
 same?


 I like to keep error messages generated by different parts of the  
 compiler slightly different - makes it easier to track them down.


Try using message IDs like most professional designers do. They are LOTS  
more easier to track, document and maintain.

-- 
Derek Parnell
Melbourne, Australia
Jul 10 2006
next sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Derek Parnell wrote:


 Try using message IDs like most professional designers do. They are LOTS
 more easier to track, document and maintain.


Yes, good idea.

Compiler error IDs are also easy to look for in documentation (see VS + MSDN
for example).



--
Jul 11 2006
parent jcc7 <jcc7_member pathlink.com> writes:
In article <e918in$lhk$1 digitaldaemon.com>, Andrei Khropov says...

Derek Parnell wrote:


 Try using message IDs like most professional designers do. They are LOTS
 more easier to track, document and maintain.


Yes, good idea.

Compiler error IDs are also easy to look for in documentation (see VS + MSDN
for example).


Even if (or especially if) Walter wasn't the one doing the documenting, message
IDs would be helpful. For example:
http://www.prowiki.org/wiki4d/wiki.cgi?ErrorMessages/CompilerErrors

jcc7
Jul 12 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 On Tue, 11 Jul 2006 15:53:11 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:
 

 James Pelcis wrote:

 I think that the error messages are good, even if they aren't 
 perfect. My point is that those four pieces of code are essentially 
 the same but all four produce different error messages.  Could they 
 all be made the same?


 I like to keep error messages generated by different parts of the 
 compiler slightly different - makes it easier to track them down.


 
 Try using message IDs like most professional designers do. They are LOTS 
 more easier to track, document and maintain.


LOL. I use message IDs in the C++ compiler. I like using the text ones 
better. (And the issue is the same, if message X comes up, I like it 
generated in one place, which means each message ID must be used only once.)
Jul 11 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 On Tue, 11 Jul 2006 15:53:11 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 James Pelcis wrote:

 I think that the error messages are good, even if they aren't 
 perfect. My point is that those four pieces of code are essentially 
 the same but all four produce different error messages.  Could they 
 all be made the same?


 I like to keep error messages generated by different parts of the 
 compiler slightly different - makes it easier to track them down.


 Try using message IDs like most professional designers do. They are 
 LOTS more easier to track, document and maintain.


 
 LOL. I use message IDs in the C++ compiler. I like using the text ones 
 better. (And the issue is the same, if message X comes up, I like it 
 generated in one place, which means each message ID must be used only 
 once.)


Perhaps a context ID would be useful?  Could even encode it into the 
message ID--set the upper N bits as the message pointer and the lower N 
bits as the location.  Still not quite as easy to track down as a search 
for an embedded string though, I'll admit.


Sean
Jul 11 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Sean Kelly wrote:

 Perhaps a context ID would be useful?  Could even encode it into the 
 message ID--set the upper N bits as the message pointer and the lower N 
 bits as the location.  Still not quite as easy to track down as a search 
 for an embedded string though, I'll admit.


I find that grepping for the string works without problems.
Jul 12 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Thu, 13 Jul 2006 05:15:40 +1000, Walter Bright  
<newshound digitalmars.com> wrote:


 Sean Kelly wrote:

 Perhaps a context ID would be useful?  Could even encode it into the  
 message ID--set the upper N bits as the message pointer and the lower N  
 bits as the location.  Still not quite as easy to track down as a  
 search for an embedded string though, I'll admit.


 I find that grepping for the string works without problems.



The commercial code that we write uses message ids because the text of the  
message is locale-dependant. We provide local-language text for each of  
the messages, external to the source code. The message text is not  
embedded in the source.

-- 
Derek Parnell
Melbourne, Australia
Jul 12 2006
parent Walter Bright <newshound digitalmars.com> writes:
Derek Parnell wrote:

 The commercial code that we write uses message ids because the text of 
 the message is locale-dependant. We provide local-language text for each 
 of the messages, external to the source code. The message text is not 
 embedded in the source.


If your app needs to do locale-dependent messages, that's the way to do it.
Jul 13 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:

 Derek Parnell wrote:

 On Tue, 11 Jul 2006 15:53:11 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 James Pelcis wrote:

 I think that the error messages are good, even if they aren't 
 perfect. My point is that those four pieces of code are essentially 
 the same but all four produce different error messages.  Could they 
 all be made the same?


 I like to keep error messages generated by different parts of the 
 compiler slightly different - makes it easier to track them down.


 Try using message IDs like most professional designers do. They are 
 LOTS more easier to track, document and maintain.


 
 LOL. I use message IDs in the C++ compiler. I like using the text ones 
 better. (And the issue is the same, if message X comes up, I like it 
 generated in one place, which means each message ID must be used only 
 once.)


Once we have a 1.0 release, it might be good to have a grep the source 
to generate a list all of the possible error messages, then put them in 
a Wiki page.
Jul 11 2006
parent jcc7 <jcc7_member pathlink.com> writes:
In article <e92428$2aet$1 digitaldaemon.com>, Don Clugston says...

Walter Bright wrote:

 Derek Parnell wrote:

 On Tue, 11 Jul 2006 15:53:11 +1000, Walter Bright 
 <newshound digitalmars.com> wrote:


 James Pelcis wrote:

 I think that the error messages are good, even if they aren't 
 perfect. My point is that those four pieces of code are essentially 
 the same but all four produce different error messages.  Could they 
 all be made the same?


 I like to keep error messages generated by different parts of the 
 compiler slightly different - makes it easier to track them down.


 Try using message IDs like most professional designers do. They are 
 LOTS more easier to track, document and maintain.


 
 LOL. I use message IDs in the C++ compiler. I like using the text ones 
 better. (And the issue is the same, if message X comes up, I like it 
 generated in one place, which means each message ID must be used only 
 once.)


Once we have a 1.0 release, it might be good to have a grep the source 
to generate a list all of the possible error messages, then put them in 
a Wiki page.


Not a bad idea.

By the way, we already have a small list of common compiler errors and their
possible solutions:
http://www.prowiki.org/wiki4d/wiki.cgi?ErrorMessages/CompilerErrors

jcc7
Jul 12 2006
prev sibling parent reply "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Walter Bright wrote:


 Derek Parnell wrote:

On Tue, 11 Jul 2006 15:53:11 +1000, Walter Bright


 <newshound digitalmars.com> wrote:

 

 James Pelcis wrote:

 I think that the error messages are good, even if they aren't  perfect.
 My point is that those four pieces of code are essentially  the same
 but all four produce different error messages.  Could they  all be made
 the same?


 
 I like to keep error messages generated by different parts of the
 compiler slightly different - makes it easier to track them down.


 
 Try using message IDs like most professional designers do. They are LOTS
 more easier to track, document and maintain.


 
 LOL. I use message IDs in the C++ compiler. I like using the text ones
 better. (And the issue is the same, if message X comes up, I like it
 generated in one place, which means each message ID must be used only once.)


I don't see a controversy here. Look at Microsoft C++ compilers: they display
both an error ID and a sensible text message.

--
Jul 12 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Andrei Khropov wrote:

 I don't see a controversy here. Look at Microsoft C++ compilers: they display
 both an error ID and a sensible text message.


Displaying the ID pushes the useful part of the message off to the right 
where it wraps or you have to use the scroll bar.

Message IDs are useful for:

1) Memory is extremely tight, and you don't want to load the error 
messages into memory unless an actual error occurs.

2) You store the messages as a Windows 'resource', which was done 
because of (1).

3) You want to be able to ship the message file off to someone else who 
can translate them to foreign languages, so the application can be 
internationalized without changing the executable.

4) You're writing some automated error message parsing tool.

None of these are an issue for dmd right now. If they ever do become an 
issue, it can be changed.
Jul 12 2006
parent "Andrei Khropov" <andkhropov nospam_mtu-net.ru> writes:
Walter Bright wrote:


 Andrei Khropov wrote:

 I don't see a controversy here. Look at Microsoft C++ compilers: they
 display both an error ID and a sensible text message.


 
 Displaying the ID pushes the useful part of the message off to the right
 where it wraps or you have to use the scroll bar.


Hmm, IMHO it's the matter of proper formatting.
It may look like:

-----------------------------------
test2.d(3): error E1234: circular reference of typedef bar
-----------------------------------
or 
-----------------------------------
test2.d(3): error E1234:
    circular reference of typedef bar
-----------------------------------

vs present

----------------------------------
test2.d(3): circular reference of typedef bar
----------------------------------

Anyway most people now have more horizonal space than 80 chars :) 


 
 Message IDs are useful for:
 
 1) Memory is extremely tight, and you don't want to load the error messages
 into memory unless an actual error occurs.
 
 2) You store the messages as a Windows 'resource', which was done because of
 (1).


I agree that these are not important issues now.


 
 3) You want to be able to ship the message file off to someone else who can
 translate them to foreign languages, so the application can be
 internationalized without changing the executable.


This maybe an issue. I haven't ever seen localized compilers however.


 
 4) You're writing some automated error message parsing tool.


I think this point is important.
Message ID may also serve as a good pointer to documentation that explains the
issue in more detail (good IDE may actually turn it into a hyperlink).




--
Jul 12 2006
prev sibling next sibling parent Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

d-bugmail puremagic.com schrieb am 2006-07-11:

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



 module test1;

 typedef foo bar;
 typedef bar foo;

 void main () {
         foo blah;
 }

 C:\programs>dmd test1.d -v
 parse     test1
 semantic  test1
 semantic2 test1
 semantic3 test1
 Stack overflow


 Without an error message, this can be almost impossible to track down.


Added to DStress as
http://dstress.kuehne.cn/nocompile/t/typedef_16_A.d
http://dstress.kuehne.cn/nocompile/t/typedef_16_B.d
http://dstress.kuehne.cn/nocompile/t/typedef_16_C.d

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFEtPJCLK5blCcjpWoRAh+RAKCIdNicwk00u/fd168FZwTvD1KMcACbBje0
QZ/VgaD6DZfkW3+Bg2tjzzA=
=UTha
-----END PGP SIGNATURE-----
Jul 12 2006
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=249


jpelcis gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED





Fixed DMD 0.163.

Circular typedefs are detected.


--
Jul 18 2006