
Amazing feats of Clang Error Recovery - pieter
http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html
======
jlangenauer
As someone pointed out on Reddit, what this is, is _superb_ attention to
detail.

The merge conflict marker recognition at the end actually brought a smile to
my face. I would be very happy if my products would produce such a reaction in
my customers.

~~~
necrecious
I wonder if it is due to involvement from Apple? Apple products are known for
paying attention to what seems like trivial detail but is actually important
to the end user experience.

------
scott_s
If you're doing template meta-programming in C++, those long type names are
more than just a nuisance. They are a program unto themselves - a declarative
program which requires similar thinking to that of Prolog. What would have
helped me when I was having to provide wrappers to uBlas
([http://www.boost.org/doc/libs/1_42_0/libs/numeric/ublas/doc/...](http://www.boost.org/doc/libs/1_42_0/libs/numeric/ublas/doc/index.htm))
is if the compiler had formatted the type names as programs. I could only
understand the error once I did that myself; otherwise, it was impossible to
see.

For people not doing template meta-programming, I agree using the typedefs is
better. But even if you're just using a library that makes use of template
metaprogramming - such as uBlas - it could help you figure out why you're
using it wrong.

------
seiji
The gcc error messages remind me of rms standing behind you yelling, "error:
expected '=', ',', ';', 'asm' or '__attribute__' before '*' token (you
idiot)!"

gcc error outputs are remnants of a bygone era where your brain contained the
source of the compiler and the entire language specification. You are supposed
to feel bad when you fail to please the parser (you wrote the entire compiler
suite and implemented the language spec yourself after all, didn't you?).

Clang error messages softly whisper sweet nothings of suggestions and
encouragement. You effortlessly resolve your typos and misconceptions. Before
you know it, you're back into Productive Working Land having circumnavigated
ancient realms of error messages from the past 20 years.

------
fragmede
The merge conflict detection is a great idea, I wonder if there would be any
value in also trying to compile the two versions and error reporting on the
two versions. Depending on the nature of the conflict, I can imagine some
cases where this would be useful.

------
1amzave
Very cool in general, though I think it might take me a while to get used to
compiler messages of the form "...maybe you meant <suggestion>?". The extra
effort in checking things is certainly appreciated, it's really just the
phrasing that I find odd -- personal pronouns are a little too "word-
processor-ish", if that makes any sense (it just doesn't sound like something
I expect to hear from a C compiler, really). I might find it less jarring if
it were phrased as "...(suggestion: <suggestion>)" instead, or even just
without the "you meant".

~~~
sorbits
There already is a few examples of gcc giving helpful hints (although nothing
like LLVM).

For example (t.cc):

    
    
        template <typename C>
        void test (C c) { C::iterator it = begin(); }
        ⋮
        test(std::vector<int>());
    

Shows this error (with a note about what the programmer likely meant):

    
    
        t.cc: In function ‘void test(C)’:
        t.cc:2: error: expected `;' before ‘it’
        t.cc: In function ‘void test(C) [with C = std::vector<int, std::allocator<int> >]’:
        t.cc:7:   instantiated from here
        t.cc:2: error: dependent-name ‘C::iterator’ is parsed as a
                       non-type, but instantiation yields a type
        t.cc:2: note: say ‘typename C::iterator’ if a type is meant

------
zellux
Wow, that will help C beginners greatly!

~~~
kingkilr
God yes. I remember when I started with C++ I was coming from Python so I was
using ' and " interchangably (I guess the fact that they were different hadn't
been covered in class yet). I don't remember how I caught that I was doing it
wrong, but the exception messages sucked.

------
leif
...but, but, now I need to learn a whole new set of error messages!

~~~
petsos
Personally I rarely look at the actual gcc error messages, because most of the
time they are useless. I just note the line number and directly look at the
code.

~~~
ajuc
You are too cruel to poor gcc.

They are no useless, you just have to remember which combination of messages
having nothing to do with your code could be caused by what sort of errors.

Gcc makes sure we will remember these rules better by making it painful and
thus more vivid in memories.

Also - real fun begins, when you forgot semicolon after the class definition
in your header, and error shows in different file.

------
wendroid
As "amazing" as this different type of error correction is, doesn't it point
to the fact that C++ is hopeless in and of itself.

When I'm using a language, alarm bells ring when I find myself needing to type
something like :

std::vector<char> v(std::istream_iterator<char>(ifs),
std::istream_iterator<char>());

~~~
signa11
typedefs might help...

~~~
mahmud
I agree 100% the parent is off-topic and inflammatory, but, please, typedefs
are not the solution.

With C++ most of the time, one is either consuming a huge/important library
(even an OS SDK) or writing one. If you're consuming the librarie(s), you just
can't go around typedefing important APIs, or you will end up maintaining a
nightmare of a fork. And if you're writing one, the sensible thing to do is to
stick with a tangible subset of C++, like most good libraries do.

Seriously, if your C++ code starts to look ugly, you're probably using the
language to its _full potential_. Don't do that. Scale back to a manageable
C-like subset; And no, you can't grow your C++ code-base to a blissful
Greenspun-esque nirvana; more C++ begets, well, MORE C++. Those multi-page
Doxygen class listings and woolly dependency diagrams never gel and mesh into
something organic. The code-base just grows diagonally, and orthogonal to your
intended direction..

