PATCH: Fix wording in error

[Richard Smith]

On Thu, Apr 30, 2015 at 11:08 PM, Nick Lewycky <nlewycky at google.com> wrote:

> On 30 April 2015 at 19:14, Richard Smith <richard at metafoo.co.uk> wrote:
>
>> On Thu, Apr 30, 2015 at 6:50 PM, Nick Lewycky <nlewycky at google.com>
>> wrote:
>>
>>> The thing that the brackets go after is not always an unqualified-id
>>> (testcase included). Switch the word for "name".
>>>
>>
>> Seems reasonable. While we're here... a diagnostic should generally
>> describe the problem before / instead of describing what we think is the
>> right solution. So something like "unexpected brackets; to declare an
>> array, put the brackets after the name" would seem better phrasing?
>>
>
> Ordinarily I agree, but not in this case. The error is that you put the
> brackets here instead of there. There is no underlying error, we
> unambiguously understand what you were trying to write but that simply
> isn't what C++ says. That the brackets were unexpected here doesn't impart
> any information if we're already saying the brackets need to go there
> instead.
>

> If we go down this road, I'd rather say "brackets are not allowed here; to
> declare an array, put the brackets after the name" since that indicates
> that we clearly and unambiguously understood it, C++ just wouldn't let us
> compile it.
>

Sure, that seems like an improvement.

We could try to explain the grammar, ala. "brackets are a
> trailing-type-specifier and must be placed after the name" but that seems
> excess jargon.
>
> I suppose we could say some form of "expected type specifier in
> declaration; to declare an array, place the brackets after the name"? This
> is the wording that I think has the best chance of being helpful if the
> compiler and programmer have two entirely different ideas of what grammar
> productions we've followed to get here.
>

There are two issues with the current wording ("unqualified-id" aside).

One issue is that we're assuming that we know what's wrong (just as you did
above), and that assumption is not necessarily correct: for instance, we
might be recovering from a different error, or this could be a vexing parse
issue with a lambda expression or Obj-C message send, or it could be a
C++11 attribute with too few brackets, or a slightly misplaced
single-bracket MS attribute. In the case where our assumption is wrong, the
fact that we *only* suggest a wrong fix, and don't even explain why we
think our fix is right, is a problem. Our current diagnostic doesn't even
mention that we think the code is trying to declare an array.

The other issue is that it sounds like we're chastising the user (it can be
read as if we're saying "the brackets go over here, dummy"), which is not
great if we're right and even worse if we're wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150501/fb3f61db/attachment.html>