[cfe-dev] Clang parser diagnostics

[Sebastian Redl]

Ken Camann wrote:
> If you type something like:
>
> "x = 3 * * 4"
>
> it will point to the second "*" and say "expected expression", because
> a node for the operator precedence parser was expected.  However, this
> is not really in keeping with the design philosophy of very expressive
> error messages.
>   
I personally think the error message is actually pretty good. It could
be better, but what you describe below doesn't feel like an improvement
to me.
> If I understand it right, the problem is this: you want to be sure you
> don't generate multiple errors that are really all the same error.
>   
Yes, this is very important. You're a Visual Studio user - you know what
happens when you type
itn variable;
You usually get three errors from that simple typo.
The underlying principle of this rule is: don't clutter the diagnostics
output. Aside from "generate a single error message per actual error"
there are some more rules that can be derived from this:
- Keep error messages as short as possible without losing expressiveness.
- Only generate information that is genuinely useful to the user.
> However, the caller of ParseCastExpression is aware of more useful
> information about why the expression was expected, so it could give a
> more useful message like "a binary operator should not follow another
> binary operator".
I believe we try to generate positive messages whenever possible, i.e.
"expression expected" instead of "don't write an operator here". They
are, in general, more informative to the user. (That's why I'm quite
happy with the message here already.) An improved message would be,
"right operand expression expected". But since we have caret
diagnostics, that feels almost superfluous.
> From what I understand, this is why you introduced "notes",
>   
Not really. Notes are for pointing out related information that is
somewhere else in the source code - the declaration of the function you
just called with incorrect arguments, for example.
> which are a very nice idea even though they don't seem to be present
> in this case.  However, that made me think of this situation:
>
> x = 3 * (a really complicated and malformed parenthetical expression)
>
> as you exit from somewhere in there, you will get a wall of "note
> spam" and probably most of it is not that necessary.  The user kind of
> gets the point about what went wrong after the first one or two notes,
> and then the rest would actually be more confusing to show (like those
> "instantiated from here..." template errors).  I can think of a whole
> bunch of ways to handle this, but I don't really like any of them.  So
> I thought I'd ask what (if anything) you guys plan to do in the
> future, since I usually like the ideas in clang.  Perhaps tons of
> notes should always be generated, and it is the responsibility of the
> user of the diagnostic client to wade through them?
No. Although I'm not at all the one making decisions in Clang, I can
state with high certainty that there is no intention to introduce tons
of notes anywhere.
>   I don't want to
> pick something, let my parser get much bigger with diagnostics
> everywhere, then change the design later if someone has already got a
> better idea.
>   
Something we do in some situations where very generic parsers should
emit a diagnostic is to have the caller pass the diagnostic ID to the
generic code. This means that all diagnostics in this situations need
the same set of parameters, but that's usually fine. Follow the code
path for parsing variable initializers for an example.

Sebastian