www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - An example of Clang error messages

reply bearophile <bearophileHUGS lycos.com> writes:
Found in Reddit:
http://zi.fi/shots/clang.png

It shows that there's some space for improvements in the error messages given
by future D compilers (like a LDC-like compiler for D2 based on LLVM) too.

Bye,
bearophile
Mar 04 2010
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thu, Mar 04, 2010 at 01:50:10PM -0500, bearophile wrote:
 It shows that there's some space for improvements in the error messages given
by future D compilers (like a LDC-like compiler for D2 based on LLVM) too.
You should try Digital Mars C. Its error messages are similar to that, though I don't think it has the built in spellchecker. The ^ pointing to where it is on the line is something it's done for many many years, though it isn't really that useful anyway in practice.
 
 Bye,
 bearophile
-- Adam D. Ruppe http://arsdnet.net
Mar 04 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Adam D. Ruppe wrote:
 You should try Digital Mars C. Its error messages are similar to that,
 though I don't think it has the built in spellchecker.
 
 The ^ pointing to where it is on the line is something it's done for many
 many years, though it isn't really that useful anyway in practice.
I dropped the ^ thing that showed the source line and position where the error was, because nobody ever said they liked it. There's always space for improvement in error messages. Note that clang is a C compiler, not a C++ one. It's a *lot* harder to generate sensible error messages for C++ than a simple language like C. The spell checker idea is a good one.
Mar 04 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Note that clang is a C compiler, not a C++ one.<
There's also Clang++ that has few days ago compiled itself for the first time :-) Bye, bearophile
Mar 04 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright:
 Note that clang is a C compiler, not a C++ one.<
There's also Clang++ that has few days ago compiled itself for the first time :-)
Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too! The hard work of implementing C++ correctly was just beginning, though.
Mar 04 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too! The 
 hard work of implementing C++ correctly was just beginning, though.
C'mon Walter, give them some credit, wish them some luck, I think they will be able to compile a good percentage of Boost in less than 15 years ;-) Bye, bearophile
Mar 04 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Walter Bright:
 Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too!
 The hard work of implementing C++ correctly was just beginning,
 though.
C'mon Walter, give them some credit, wish them some luck, I think they will be able to compile a good percentage of Boost in less than 15 years ;-)
Given a solid C compiler, writing a reasonably compliant C++ compiler takes an additional 10 man years, in the best of circumstances. More reasonably, 20.
Mar 04 2010
parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 bearophile wrote:
 Walter Bright:
 Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too!
 The hard work of implementing C++ correctly was just beginning,
 though.
C'mon Walter, give them some credit, wish them some luck, I think they will be able to compile a good percentage of Boost in less than 15 years ;-)
Given a solid C compiler, writing a reasonably compliant C++ compiler takes an additional 10 man years, in the best of circumstances. More reasonably, 20.
How many man years would you assume writing a full D compiler takes? (Frontend starting from scratch, using an existing backend.)
Mar 04 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 How many man years would you assume writing a full D compiler takes? 
 (Frontend starting from scratch, using an existing backend.)
I don't know. Somewhere in between. Remember that EDG reported that it took them 3 man-years just to implement one C++ feature - exported templates - and the EDG guys know what they're doing around compilers. But there's little reason to implement a D compiler from scratch. For open source uses, you can just go ahead and use dmd. For closed, proprietary uses, we can work something out.
Mar 04 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 But there's little reason to implement a D compiler from scratch.<
I'm ignorant about this topic, but I think there are various ways to create a new D front-end: - Copy the C++ code of DMD and create a small middle-end to adapt it to something else, LDC and GDC have done this. This is the faster way to produce something that works. - Translate the dmd front-end to D code that looks as much as possible as the original C++. And when it works well, then it can slowly be adapted to use D features, etc. The advantage of this way is that you then can program in D instead of C++, and later people that want to help in the development of this don't need to know C++ too. Another advantage is that such good amount of D code can give ideas to improve D itself. I think someone has tried to do this, but I think there's no working compiler yet (maybe DIL?). - Create a front-end in D almost from scratch. Maybe Dlang is trying to become this. The advantage is that it's modelled on Clang, that has a nice modular design. Bye, bearophile
Mar 04 2010
next sibling parent reply "Aziz K." <aziz.koeksal gmail.com> writes:
Hi,

 - Create a front-end in D almost from scratch.
I've been developing a D compiler, and I started completely from scratch. ;) But the most difficult part still lies ahead of me: Semantic Analysis. That's why DIL (looks good in caps I guess) still can't produce any binaries. At least it can generate decent documentation. So it's not entirely useless. :) Btw, I think you mean dang: http://www.dsource.org/projects/dang It's been inactive for 2 years now.
Mar 05 2010
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
Aziz K. wrote:

 That's why DIL (looks good in caps I guess)
More correctly: DİL ;) Ali
Mar 05 2010
parent "Aziz K." <aziz.koeksal gmail.com> writes:
 More correctly: DİL ;)
Yeah, but English users won't like that. :P Turkish speakers can refer to it as DİL if they like.
Mar 06 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 3/5/10 02:10, bearophile wrote:
 Walter Bright:
 But there's little reason to implement a D compiler from scratch.<
I'm ignorant about this topic, but I think there are various ways to create a new D front-end: - Copy the C++ code of DMD and create a small middle-end to adapt it to something else, LDC and GDC have done this. This is the faster way to produce something that works. - Translate the dmd front-end to D code that looks as much as possible as the original C++. And when it works well, then it can slowly be adapted to use D features, etc. The advantage of this way is that you then can program in D instead of C++, and later people that want to help in the development of this don't need to know C++ too. Another advantage is that such good amount of D code can give ideas to improve D itself. I think someone has tried to do this, but I think there's no working compiler yet (maybe DIL?). - Create a front-end in D almost from scratch. Maybe Dlang is trying to become this. The advantage is that it's modelled on Clang, that has a nice modular design. Bye, bearophile
I add to the above: If you want to create an application or library that uses a D front end, for example an IDE with refactoring and autocompletion, you are forced to write it in C++ and use the GPL license. BTW the DMD front end is probably not very good for this sort of things. /Jacob Carlborg
Mar 05 2010
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:
 If you want to create an application or library that uses a D front end, 
 for example an IDE with refactoring and autocompletion, you are forced 
 to write it in C++ and use the GPL license. BTW the DMD front end is 
 probably not very good for this sort of things.
An easy (but admittedly incomplete) solution to this is to have dmd generate json output, which is easily imported by an IDE.
Mar 05 2010
parent Jacob Carlborg <doob me.com> writes:
On 3/5/10 11:24, Walter Bright wrote:
 Jacob Carlborg wrote:
 If you want to create an application or library that uses a D front
 end, for example an IDE with refactoring and autocompletion, you are
 forced to write it in C++ and use the GPL license. BTW the DMD front
 end is probably not very good for this sort of things.
An easy (but admittedly incomplete) solution to this is to have dmd generate json output, which is easily imported by an IDE.
Yes, that's the problem, it will be incomplete. I might be good as a first solution to get things going but not in the long run. You'll always end up with things you can't do and you feel you're limited by things you can do.
Mar 05 2010
prev sibling parent reply dolive <dolive89 sina.com> writes:
Jacob Carlborg д:

 On 3/5/10 02:10, bearophile wrote:
 Walter Bright:
 But there's little reason to implement a D compiler from scratch.<
I'm ignorant about this topic, but I think there are various ways to create a new D front-end: - Copy the C++ code of DMD and create a small middle-end to adapt it to something else, LDC and GDC have done this. This is the faster way to produce something that works. - Translate the dmd front-end to D code that looks as much as possible as the original C++. And when it works well, then it can slowly be adapted to use D features, etc. The advantage of this way is that you then can program in D instead of C++, and later people that want to help in the development of this don't need to know C++ too. Another advantage is that such good amount of D code can give ideas to improve D itself. I think someone has tried to do this, but I think there's no working compiler yet (maybe DIL?). - Create a front-end in D almost from scratch. Maybe Dlang is trying to become this. The advantage is that it's modelled on Clang, that has a nice modular design. Bye, bearophile
I add to the above: If you want to create an application or library that uses a D front end, for example an IDE with refactoring and autocompletion, you are forced to write it in C++ and use the GPL license. BTW the DMD front end is probably not very good for this sort of things. /Jacob Carlborg
approve to implement D frontend from scratch with D2. Should be to absorb more committer of those, like ddmd and dil author, do not just one person's project, to form a more powerful community . vote ? dolive
Mar 05 2010
parent reply Jacob Carlborg <doob me.com> writes:
On 3/5/10 20:43, dolive wrote:
 Jacob Carlborg �:

 On 3/5/10 02:10, bearophile wrote:
 Walter Bright:
 But there's little reason to implement a D compiler from scratch.<
I'm ignorant about this topic, but I think there are various ways to create a new D front-end: - Copy the C++ code of DMD and create a small middle-end to adapt it to something else, LDC and GDC have done this. This is the faster way to produce something that works. - Translate the dmd front-end to D code that looks as much as possible as the original C++. And when it works well, then it can slowly be adapted to use D features, etc. The advantage of this way is that you then can program in D instead of C++, and later people that want to help in the development of this don't need to know C++ too. Another advantage is that such good amount of D code can give ideas to improve D itself. I think someone has tried to do this, but I think there's no working compiler yet (maybe DIL?). - Create a front-end in D almost from scratch. Maybe Dlang is trying to become this. The advantage is that it's modelled on Clang, that has a nice modular design. Bye, bearophile
I add to the above: If you want to create an application or library that uses a D front end, for example an IDE with refactoring and autocompletion, you are forced to write it in C++ and use the GPL license. BTW the DMD front end is probably not very good for this sort of things. /Jacob Carlborg
approve to implement D frontend from scratch with D2. Should be to absorb more committer of those, like ddmd and dil author, do not just one person's project, to form a more powerful community . vote ? dolive
Sounds like a good idea, though I would choose D1 and tango.
Mar 06 2010
parent dolive <dolive89 sina.com> writes:
Jacob Carlborg д:

 On 3/5/10 20:43, dolive wrote:
 Jacob Carlborg �:

 On 3/5/10 02:10, bearophile wrote:
 Walter Bright:
 But there's little reason to implement a D compiler from scratch.<
I'm ignorant about this topic, but I think there are various ways to create a new D front-end: - Copy the C++ code of DMD and create a small middle-end to adapt it to something else, LDC and GDC have done this. This is the faster way to produce something that works. - Translate the dmd front-end to D code that looks as much as possible as the original C++. And when it works well, then it can slowly be adapted to use D features, etc. The advantage of this way is that you then can program in D instead of C++, and later people that want to help in the development of this don't need to know C++ too. Another advantage is that such good amount of D code can give ideas to improve D itself. I think someone has tried to do this, but I think there's no working compiler yet (maybe DIL?). - Create a front-end in D almost from scratch. Maybe Dlang is trying to become this. The advantage is that it's modelled on Clang, that has a nice modular design. Bye, bearophile
I add to the above: If you want to create an application or library that uses a D front end, for example an IDE with refactoring and autocompletion, you are forced to write it in C++ and use the GPL license. BTW the DMD front end is probably not very good for this sort of things. /Jacob Carlborg
approve to implement D frontend from scratch with D2. Should be to absorb more committer of those, like ddmd and dil author, do not just one person's project, to form a more powerful community . vote ? dolive
Sounds like a good idea, though I would choose D1 and tango.
Walter Bright certainly not agree to, Because there are too many bug of d the current, d is Incompetent . dolive
Mar 06 2010
prev sibling parent reply Jerry Quinn <jlquinn optonline.net> writes:
Walter Bright Wrote:

 grauzone wrote:
 How many man years would you assume writing a full D compiler takes? 
 (Frontend starting from scratch, using an existing backend.)
But there's little reason to implement a D compiler from scratch. For open source uses, you can just go ahead and use dmd. For closed, proprietary uses, we can work something out.
Hi, me again. Following up on this comment, can I bring up the proposal of contributing a snapshot of the dmd frontend to the GCC project? I think for D to be really viable in GCC, it must be a part of the source tree. I hope I'm not being a pest. Thanks, Jerry
Mar 04 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jerry Quinn wrote:
 Hi, me again.  Following up on this comment, can I bring up the
 proposal of contributing a snapshot of the dmd frontend to the GCC
 project?  I think for D to be really viable in GCC, it must be a part
 of the source tree.
 
 I hope I'm not being a pest.
No, you're not being a pest, I just haven't gotten it done yet.
Mar 04 2010
prev sibling parent Steve Teale <steve.teale britseyeview.com> writes:
On Thu, 04 Mar 2010 22:04:47 -0500, Jerry Quinn wrote:

 Walter Bright Wrote:
 
 grauzone wrote:
 How many man years would you assume writing a full D compiler takes?
 (Frontend starting from scratch, using an existing backend.)
But there's little reason to implement a D compiler from scratch. For open source uses, you can just go ahead and use dmd. For closed, proprietary uses, we can work something out.
Hi, me again. Following up on this comment, can I bring up the proposal of contributing a snapshot of the dmd frontend to the GCC project? I think for D to be really viable in GCC, it must be a part of the source tree. I hope I'm not being a pest. Thanks, Jerry
Good to hear from you again Jerry - please keep it up. There were fairly recent signs of life from GDC, but they seem to have dropped off. I have been trying to move the most recent GDC version to GCC 4.4.3,but there have been breaking changes there, so I have a long way to go. Steve
Mar 05 2010
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 The spell checker idea is a good one.
I have seen it used for the first time in Mathematica, even very old versions of it. It's handy. In Python I have written something similar that works at runtime. Bye, bearophile
Mar 04 2010
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 3/4/10 20:19, Walter Bright wrote:
 Adam D. Ruppe wrote:
 You should try Digital Mars C. Its error messages are similar to that,
 though I don't think it has the built in spellchecker.

 The ^ pointing to where it is on the line is something it's done for many
 many years, though it isn't really that useful anyway in practice.
Why would you remove such a useful feature if it's already implemented? I think too often people just complain when they don't like something and when they do like something they just sit silently. Perhaps they use IDEs when compiling that take them directly to the file and line number when they get a compiler error.
 I dropped the ^ thing that showed the source line and position where the
 error was, because nobody ever said they liked it.

 There's always space for improvement in error messages. Note that clang
 is a C compiler, not a C++ one. It's a *lot* harder to generate sensible
 error messages for C++ than a simple language like C.

 The spell checker idea is a good one.
Mar 05 2010
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:
 Why would you remove such a useful feature if it's already implemented? 
 I think too often people just complain when they don't like something 
 and when they do like something they just sit silently. Perhaps they use 
 IDEs when compiling that take them directly to the file and line number 
 when they get a compiler error.
It really didn't add much of any useful value, likely because one line of source code all by itself just doesn't give enough context. And yes, people do use IDEs or editors that parse the error message and put the cursor on the correct line, which is far more useful. One annoying problem with it is each error consumes 3 lines instead of one, and stuff you wanted to see got scrolled off the top of the window. It's still in the DMC C and C++ compiler, try it out. I just didn't implement it for the D compiler.
Mar 05 2010
next sibling parent Jacob Carlborg <doob me.com> writes:
On 3/5/10 11:54, Walter Bright wrote:
 Jacob Carlborg wrote:
 Why would you remove such a useful feature if it's already
 implemented? I think too often people just complain when they don't
 like something and when they do like something they just sit silently.
 Perhaps they use IDEs when compiling that take them directly to the
 file and line number when they get a compiler error.
It really didn't add much of any useful value, likely because one line of source code all by itself just doesn't give enough context. And yes, people do use IDEs or editors that parse the error message and put the cursor on the correct line, which is far more useful. One annoying problem with it is each error consumes 3 lines instead of one, and stuff you wanted to see got scrolled off the top of the window. It's still in the DMC C and C++ compiler, try it out. I just didn't implement it for the D compiler.
Oh, I got the impression that you first implemented it in the DMC compiler and then removed it, also form the DMC compiler. Now I understand.
Mar 05 2010
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2010-03-05 05:54:56 -0500, Walter Bright <newshound1 digitalmars.com> said:

 It really didn't add much of any useful value, likely because one line 
 of source code all by itself just doesn't give enough context. And yes, 
 people do use IDEs or editors that parse the error message and put the 
 cursor on the correct line, which is far more useful.
 
 One annoying problem with it is each error consumes 3 lines instead of 
 one, and stuff you wanted to see got scrolled off the top of the window.
Xcode displays Clang errors by highlighting all the relevant parts in the source document. For instance, this error: clang.c:15:37:{15:34-15:36}: error: no member named 'horisontal' will display the error as you can see here: http://michelf.com/img/shots/xcode-clang-error.png I agree it isn't great on the command line, but just because something isn't great on the command line doesn't mean it can't be great elsewhere. I think it's useful to track this information., even if you choose to not display it by default. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 05 2010
parent Walter Bright <newshound1 digitalmars.com> writes:
Michel Fortin wrote:
 I agree it isn't great on the command line, but just because something 
 isn't great on the command line doesn't mean it can't be great 
 elsewhere. I think it's useful to track this information., even if you 
 choose to not display it by default.
I've seen the picture and accompanying article. One should be careful about interpreting it, though. An error message may be a perfect fit for one context, and woefully miss the point in another, even though the compiler cannot tell the cases apart. This is a particular problem in C++ because certain constructs, like f(g), can have all kinds of different meanings. So if the user makes a mistake with f(g), it's impossible for the compiler to accurately know which of all those meanings was intended, so the error message winds up being something little better than: "some error happened compiling f(g)" and the source of the user's actual mistake may be quite far away from there.
Mar 05 2010
prev sibling parent reply Marianne Gagnon <auria.mg gmail.com> writes:
Walter Bright Wrote:

 Jacob Carlborg wrote:
 Why would you remove such a useful feature if it's already implemented? 
 I think too often people just complain when they don't like something 
 and when they do like something they just sit silently. Perhaps they use 
 IDEs when compiling that take them directly to the file and line number 
 when they get a compiler error.
It really didn't add much of any useful value, likely because one line of source code all by itself just doesn't give enough context. And yes, people do use IDEs or editors that parse the error message and put the cursor on the correct line, which is far more useful. One annoying problem with it is each error consumes 3 lines instead of one, and stuff you wanted to see got scrolled off the top of the window. It's still in the DMC C and C++ compiler, try it out. I just didn't implement it for the D compiler.
I am not familiar with the error messages given by DMC; in my own experience, I found that feature useful when e.g. you have something like x = (a + b) * (c + d) / (e + f); and you have error message "invalid operands to +" or so. Then x = (a + b) * (c + d) / (e + f); ^ helps. Of course, a better error message saying "variable 'c' of type 'Foo' cannot be used as operand to +" works too
Mar 05 2010
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Marianne Gagnon" <auria.mg gmail.com> wrote in message 
news:hmrbgm$8be$1 digitalmars.com...
 Walter Bright Wrote:

 Jacob Carlborg wrote:
 Why would you remove such a useful feature if it's already implemented?
 I think too often people just complain when they don't like something
 and when they do like something they just sit silently. Perhaps they 
 use
 IDEs when compiling that take them directly to the file and line number
 when they get a compiler error.
It really didn't add much of any useful value, likely because one line of source code all by itself just doesn't give enough context. And yes, people do use IDEs or editors that parse the error message and put the cursor on the correct line, which is far more useful. One annoying problem with it is each error consumes 3 lines instead of one, and stuff you wanted to see got scrolled off the top of the window. It's still in the DMC C and C++ compiler, try it out. I just didn't implement it for the D compiler.
I am not familiar with the error messages given by DMC; in my own experience, I found that feature useful when e.g. you have something like x = (a + b) * (c + d) / (e + f); and you have error message "invalid operands to +" or so. Then x = (a + b) * (c + d) / (e + f); ^ helps. Of course, a better error message saying "variable 'c' of type 'Foo' cannot be used as operand to +" works too
Many compilers handle that by providing both a line number and a "column" number (not actually a true column number, as tabs get counted as 1, but that's as it should be since tabsize is an editor setting anyway.)
Mar 05 2010
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Marianne Gagnon wrote:
 I am not familiar with the error messages given by DMC; in my own
 experience, I found that feature useful when e.g. you have something
 like
 
 x = (a + b) * (c + d) / (e + f);
 
 and you have error message "invalid operands to +" or so. Then
 
 x = (a + b) * (c + d) / (e + f); ^
 
 helps. Of course, a better error message saying "variable 'c' of type
 'Foo' cannot be used as operand to +" works too
Here's what DMC does: x = (a + b) * (c + d) / (e + f); ^ test.cpp(6) : Error: illegal operand types Had: Foo and: int and here's what DMD does: test.d(6): Error: incompatible types for ((c) + (d)): 'Foo' and 'int'
Mar 05 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

 Here's what DMC does:
 
      x = (a + b) * (c + d) / (e + f);
                          ^
 test.cpp(6) : Error: illegal operand types
 Had: Foo
 and: int
 
 and here's what DMD does:
 
 test.d(6): Error: incompatible types for ((c) + (d)): 'Foo' and 'int'
[What DMD currently does (plus the last thing you have very quickly implemented, I have asked for that feature of Mathematica lot of time ago) is enough for me.] For a human those two error messages give about the same information. But for a IDE that has to parse the error messages to show something graphically the error message with the "^" can be better. Regarding the excessive amount of lines of error messages shown on the command line when you use the "^", with DMD I usually only read the first error message or the few first ones, ignoring the successive error messages, because the successive ones are usually useless. With GCC I sometimes use a compilation flag (-Wfatal-errors) that when present makes the compiler show only the first of few first error messages. Bye, bearophile
Mar 05 2010
next sibling parent BCS <none anon.com> writes:
Hello bearophile,

 For a human those two error messages give about the same information.
 But for a IDE that has to parse the error messages to show something
 graphically the error message with the "^" can be better.
Even better for an IDE: filename.d:linenum:col: Error message -- ... <IXOYE><
Mar 05 2010
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 3/5/10 19:42, bearophile wrote:
 Walter Bright:

 Here's what DMC does:

       x = (a + b) * (c + d) / (e + f);
                           ^
 test.cpp(6) : Error: illegal operand types
 Had: Foo
 and: int

 and here's what DMD does:

 test.d(6): Error: incompatible types for ((c) + (d)): 'Foo' and 'int'
[What DMD currently does (plus the last thing you have very quickly implemented, I have asked for that feature of Mathematica lot of time ago) is enough for me.] For a human those two error messages give about the same information. But for a IDE that has to parse the error messages to show something graphically the error message with the "^" can be better.
I think column number would be a lot easier for an IDE to parse than a "^".
 Regarding the excessive amount of lines of error messages shown on the command
line when you use the "^", with DMD I usually only read the first error message
or the few first ones, ignoring the successive error messages, because the
successive ones are usually useless. With GCC I sometimes use a compilation
flag (-Wfatal-errors) that when present makes the compiler show only the first
of few first error messages.

 Bye,
 bearophile
Mar 06 2010
prev sibling parent reply =?ISO-8859-1?Q?Pelle_M=E5nsson?= <pelle.mansson gmail.com> writes:
On 03/05/2010 07:26 PM, Walter Bright wrote:
 and here's what DMD does:

 test.d(6): Error: incompatible types for ((c) + (d)): 'Foo' and 'int'
Adding a column number brings that to the same level of information as the ^-deal, right? Could be useful like the XCode sample from earlier. However, I like the way it is now because of the lack of false information (should the column number be wrong), and I ususally just jump to the line number anyway.
Mar 05 2010
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Pelle Mnsson wrote:
 Adding a column number brings that to the same level of information as 
 the ^-deal, right?
I've not done the column number because it has a negative impact on parsing speed and memory consumption, while providing little benefit.
Mar 05 2010
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Pelle Mnsson" <pelle.mansson gmail.com> wrote in message 
news:hmrniv$vpc$1 digitalmars.com...
 On 03/05/2010 07:26 PM, Walter Bright wrote:
 and here's what DMD does:

 test.d(6): Error: incompatible types for ((c) + (d)): 'Foo' and 'int'
Adding a column number brings that to the same level of information as the ^-deal, right?
Column number (really an offset from the start of the line, though, not an actualy "column") wouldn't be prone to error when the line includes a tab, like the ^-thing would be. Also, column number parsing is already present in many editors, but I've never seen one that parsed ^-stuff, and you'd probably have a harder time convincing editor developers to implement that since it's far less common among compilers.
 Could be useful like the XCode sample from earlier.

 However, I like the way it is now because of the lack of false information 
 (should the column number be wrong), and I ususally just jump to the line 
 number anyway.
It's possible for line numbers to be wrong too, especially when a language supports multi-line statements. And DMD in particular generates wrong line numbers when there's an error inside a string mixin. Also, many editors, like Programmer's Notepad, can jump to the line *and* column, which I personally find to be very nice when I have lines that are non-trivial (ie, frequently enough to matter).
Mar 05 2010