Multiclass diagnostics

Aaron Ballman aaron at aaronballman.com
Fri Dec 27 08:13:44 PST 2013


That's a neat idea! If I understand it correctly, what you are
suggesting is to have warn_foobar as the diagnostic, and in the code
issuing the diagnostic, have some sort of PromoteToError flag passed
to Diag so that it knows to treat the warning as an error. The
downside to this is that it makes each call site using that error a
bit more ugly and verbose, and the change likely would need some new
machinery in the diagnostic engine. I think I would rather keep the
machinery in the tablegen because it's a bit more declarative and
self-explanatory, but don't feel incredibly strongly about it.

~Aaron

On Fri, Dec 27, 2013 at 10:28 AM, Arthur O'Dwyer
<arthur.j.odwyer at gmail.com> wrote:
> Hott. Although, I wonder if similar functionality could be implemented
> in terms of the same codepath that implements
>   -Werror=attribute_pointers_only
> (or whatever this warning is named).
> I.e., have only one diagnostic instead of two, but selectively promote
> it to an error as needed.
>
> Idle thoughts,
> –Arthur
>
>
> On Fri, Dec 27, 2013 at 7:18 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> There are several instances where we have diagnostics that take a
>> warning form as well as an error form, but retain the same spelling
>> between the two forms. Eg)
>>
>> def warn_attribute_pointers_only : Warning<
>>   "%0 attribute only applies to pointer arguments">,
>>   InGroup<IgnoredAttributes>;
>> def err_attribute_pointers_only : Error<
>>   "%0 attribute only applies to pointer arguments">;
>>
>> This duplication can make it easy for the two diagnostic wordings to
>> get out of sync. For instance, with the attribute subject diagnostics,
>> there is a %select list that must remain in sync between the two
>> diagnostics.
>>
>> These two patches implement multiclass support for diagnostics.
>>
>> The llvm side of things modifies the table generator to pay attention
>> to the whether the multiclass name should be a prefix or suffix. It
>> does so by looking at whether the class name ends with an underscore.
>> So foo_ will be treated as a prefix, and anything else will be treated
>> as a suffix.
>>
>> The clang side uses the new tablegen functionality by creating a
>> warning_and_error multiclass which uses the warn_ and err_ prefixes.
>> Because they end with an underscore, they will be concatenated
>> properly to form warn_attribute_pointers_only and
>> err_attribute_pointers_only.
>>
>> If this approach seems like a good idea, I will also update the
>> tablegen documentation to note the new functionality, and can likely
>> switch over more diagnostics to using the warning_and_error base
>> multiclass.
>>
>> ~Aaron
>>
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>




More information about the cfe-commits mailing list