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.
Comment #1 by andkhropov — 2006-07-12T08:37:29Z
Walter Bright wrote:
> Derek Parnell wrote:
> >On Tue, 11 Jul 2006 15:53:11 +1000, Walter Bright
> <[email protected]> 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.
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).