Aren't there compilers better at telling the programmer what's wrong in a code?

Question

I have worked a little while with the Microsoft compiler from Visual C++ but I worked a long time with G++, and I remember often having bad times understanding what was wrong in my code with the former.

Beside binary code generation and optimisation, I think this is a very important feature of a C++ compiler: giving the programmer a clue that makes him understand as fast as possible what is wrong with his/her code. I can understand some programmers understand programming as some sort of "competition" to make less errors, but to me that's a counter productive opinion.

I once tried Clang compiler for C from the LLVM thingie, I didn't use it for a long time, but I was impressed on how explicit and easy to understand the error messages were.

What are your experiences, and how do you think this matters ?

Some WIP of C++ Clang: http://clang.llvm.org/cxx_status.html

Answer 1

From what I have seen, Clang definitely has the best error messages available.

This however comes at a cost: it takes time to develop and test.

I think therefore that this is more a mindset issue than anything else: VS and gcc are trying to provide ever more C++0x support these days, and compliance is hard to achieve, and some new features required extensive rewrite (move semantics and rvalue references come to mind).

Clang on the other hand was built with nice error reporting as an advertised feature. It's an integral part of the compiler: the very Diagnostic core has been built around this feature, with Hint, SourceRange etc...

It is also a real focus of developers (I have seen commits whose sole goals was to improve an existing error message) and suggestions on error reporting are always appreciated (either new diagnosis or improved diagnosis).

I suppose this comes at the cost of diverting manpower from other tasks. Of course, for open-source software it may not be the case, since improving diagnosis is usually a relatively trivial task it may be tackled by beginners while the lead / experienced developers may focus on core features.

Edit: Example of recent (today) commit

Chandler Carruth modified the diagnostic emitted for arrays with a negative size to include the name of the array in the error message itself, because as of C++03 the poor's man static_assert is often implemented using this trick, with the name of array being the error message intended :)

Answer 2

From my experience:

1) C++ is complicated enough to make it difficult to parse it whatsoever, not to mention parse it with good error recovery. For example, omitting ; at the end of class definition often makes it one with the following declaration/definition, thus yielding a cryptic message like:

New types cannot be defined in return type

instead of

Omitted ; after class definition

And the error is technically true! The problem is, the class def may be in one file and the error will appear in different one, which very often confuses beginner programmers (oh how many times did I fall for this one myself years ago!). But still, today's compilers try to be helpful - for example for quite some time g++ will give a hint ("did you forget a ;?") after the problem.

C++ is not perfect in most cases, but like 90% of them are quite simple to understand, and trivially simple once you know a bit better how C++ grammar looks like.

But there's a whole second level of errors out there...

---

2) Definitely the MOST sophiscated error messages a programmer may ever see are the errors related to templates and template instantiation. Such an error (just one!) often may span several screenfuls of text and an apprentice C++ programmer will panic at the very first sight. And the error underneath may be anything: even a simple typo in method name.

The problem here is simple: Templates in C++ are a programming language by themselves. No exagerrating here, they're proven to be Turing-complete :) And I believe that with the current C++, when you make a mistake with templates, there's NO reliable way for the compiler to guess "how this code is supposed to look like".

Then, the only thing the compiler can do is to say: I cannot instantiate template X with arguments A, B and C when C is a template instantiated with U, W, because C<U,W> cannot be passed as a parameter to X::foo(A,B,C<K,R>), et cetera, et cetera. Fill this with meaningful template names, meaningful method names and a lot of namespaces in between and you get lots of lines. Now, add "candidates are:" section to that and this gets LONG. Helpful and - with a little bit of patience and experience - readable, but LONG.

In fact, there was an attempt to solve this situation. It was called "concepts" and was meant to be included in the next C++ standard. Basically, a concept was to be something like a formal specificatation of the "interface" of a template.

With concepts, the above may be reduced to "the template T was declared to be instantiable with the second template parameter obeying the concept XYZ, and that template doesn't support XYZ, so I cannot instantiate T here".

But the problem is that "concepts", in order to be defined in a correct and useful manner, would be probably even more complicated than the template system itself. So they gave it up in C++0x...

So the answer is sad: The best thing we can do is to make a syntax colouring and formatting script for the compilers' error messages about templates. :)

Answer 3

As a compiler implementor I can tell you that reporting errors is the hardest part of compiler design. It means not only translating stuff, it means keeping track of how you translated it so if something goes wrong you have a "back trace" of how the compiler got there.

For example with templates, you can instantiate a template type parameter with an argument which is itself a template, and so to report an error context you have to report: the point the base type is defined, the point the template using it is defined, the point the template using it uses it, the point the outer template is defined, and the point that it is applied to the template .. and then the error may be in some method call applied to the resultant object which can't be reported until you call it so that's another point. So for a simple code like:

X<Y<T>> a; a.f();

you have 6 distinct places in the source to report, any one of which could be the position of the actual error. Even if the end user can wade through this trivial example with only 6 positions reported they have no hope of wading through a more complex example, so the compiler HAS to do some work to try to guess what it should report and what to leave out.

And all this requires keeping track of all that information.. for just about every "term" in the AST and IL. Can you imagine reporting a problem where there was overload resolution done, and an error occurs because the "wrong" overload was selected?

Answer 4

I think it does take a while to get used to a particular compiler's error messages, but once you have understood what each message means, (in my experience) you are in a good position to find the issue. Some compilers are better than others in terms of understanding what they are doing, so obviously it is worth putting some effort into generating decent messages, but at the end of the day, there is not silver bullet, you still need to examine the code manually and fix it!

It is a very hard problem to be specific about compiler errors without guessing- no one likes a smartarse less than programmers.

Answer 5

Basically, the compiler should not do anything more than pointing out which line is the culprit one and a little description of what is wrong. It is supposed you know the theory behind how general programming works and how your programming language works, thus more info from the compiler would not be needed in my humble opinion. If a compiler that does explain this kind of errors is to be made/has been done, i guess a lot of the time on it's development was used [READ: Used, not wasted] in the logic to parse those errors into human-readable and fully-explained English where that time could of been used into better optimization/standards compliance... I am not saying this is bad, but if i have to choose between a fully-fledged standard compiler such as the MSVC compiler and something a tad bit under-developed but that explains everything 100%... id go with MSVC. These are my 2 cents, bear in mind i have NOT used Clang and have no real idea of what it is. Happy coding :)

Answer 6

Honestly, if you are having problems getting your code to compile then there are much larger issues than perhaps less than ideal error messages. The compiler IS NOT a debugger.

I understand that the messages can be pretty confusing for newbs. In that case, I suggest complying often rather than after writing the whole application. It is really hard to figure out what is wrong with the code if you write code with a ton a mistakes.

For seasoned programmers though, getting code to compile should not even be an issue.

Either way, once you work with the compiler for a bit the messages are not as cryptic as you might think.