r198605 - Don't use magic constants in the digraph diagnostic
Jordan Rose
jordan_rose at apple.com
Mon Jan 6 18:19:07 PST 2014
On Jan 6, 2014, at 18:14, Alp Toker <alp at nuanti.com> wrote:
>
> On 06/01/2014 19:11, Richard Smith wrote:
>> On Mon Jan 06 2014 at 11:01:02 AM, Alp Toker <alp at nuanti.com <mailto:alp at nuanti.com>> wrote:
>>
>>
>> On 06/01/2014 18:29, Richard Smith wrote:
>> > On Mon Jan 06 2014 at 10:06:25 AM, Alp Toker <alp at nuanti.com
>> <mailto:alp at nuanti.com>
>> > <mailto:alp at nuanti.com <mailto:alp at nuanti.com>>> wrote:
>> >
>> >
>> > On 06/01/2014 17:34, Jordan Rose wrote:
>> > > This changes the message for templates in a way that is less
>> > informative.
>> >
>> > No change in output. Do you mean the string in the TableGen file
>> > is now
>> > less informative?
>> >
>> > > In other cases where we use tokens as diagnostic
>> arguments, the
>> > message makes sense whether or not the token text is quoted.
>> Here,
>> > that's not true: the problem isn't about the literal word
>> > "template" but about a particular template (like "vector").
>> Using
>> > tok::annot_template_id as if it were a real token seems wrong
>> >
>> > That was the reason I changed the "magic token kind" in use from
>> > tok::kw_template to tok::annot_template_id. tok::kw_template
>> > relates to
>> > "template" whereas tok::annot_template_id is a synonym for
>> "template
>> > name" so this appears a better choice to use as the placeholder.
>> >
>> >
>> > It's a synonym for 'template id' (a template name followed by
>> template
>> > arguments), not for 'template name'. Using it here is inappropriate.
>>
>> Diagnostics seem to call it that way, with 'template-id' not appearing
>> rarely:
>>
>> def err_template_id_not_a_type : Error<
>> "template name refers to non-type template %0">;
>>
>>
>> This looks clear and technically correct to me. We're diagnosing that the template-id X<Y> is not a type by saying that X is a non-type template name.
>>
>> I agree it's not fully appropriate, but it's more appropriate than the
>> previous tok::kw_template given that there isn't a "template"
>> keyword in
>> sight:
>>
>> D<::F> A2; // expected-error{{found '<::' after a template name which
>> forms the digraph}}
>>
>> Can you think of a better alternative to either?
>>
>>
>> Jordan's suggestion of using an enum seems fine to me. (As Aaron Ballman and I have previously discussed on-list, we should also have a mechanism to generate these enums from the .td files to avoid the magic numbers entirely.)
>
> Even with an enum there's still going to have to be a switch somewhere, and what I've really been looking for is boilerplate-free way to share code construct descriptions with the parser, sema and code completion.
>
> Agree that this change might not be the solution (especially annot_type_id) but the previous code was at least as dubious with its kw_template so I'm not keen on bringing that back to life either.
>
> So if it's OK with Jordan I'd like to mull over this for a few days to see if we can move it forward in a satisfactory way first. Will examine those threads again too.
>
> Alp.
The previous code was silly, but it was just using kw_template as a switch key. If you want to use tok::identifier there instead, that's fine, but I'd be happier if the structure were put back the way it originally was for now.
Jordan
More information about the cfe-commits
mailing list