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.
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.
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/...) 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.
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.
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.
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".
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
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.
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.
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.
Stop, comments like these are pointless when discussing a C/C++ compiler. Yes, some people dislike C++, but some people also love it, and when a new compiler offers some really neat error reporting, complaining about C++ does no good.
To the Clang team, this is damn impressive. I've never thought about a compiler detecting merge conflicts, but thats pretty cool.
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..
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.