Add 'remark' diagnostic type in clang

[Alp Toker]

On 26/02/2014 21:27, Tobias Grosser wrote:
> On 02/26/2014 10:19 PM, Chris Lattner wrote:
>> On Feb 26, 2014, at 2:22 AM, Tobias Grosser <tobias at grosser.es> wrote:
>>> 2) Adding the new severity level / the name of the diagnostic
>>>
>>> Only small issues have been found in the patch. All of them have 
>>> been addressed. The last open issues was the name of the diagnostic. 
>>> Richard
>>> proposed 'info' or 'remark'. Chris and Eric prefer to call the 
>>> severity 'info', in case there is no prior art. However, Alexander 
>>> and Arthur mentioned prior art for 'remark' in both icc and edg. 
>>> Also the comment from Arthur sounds right:
>>>
>>>   I don't know of any compiler that uses the term "informative".
>>>   Besides, that's redundant; *all* compiler diagnostics are purely
>>>   "informative" by definition. The variable here is //severity//:
>>>   fatal-error, recoverable-error, warning, remark, silent.
>>>
>>> I personally preferred 'info' first, but now came to the conclusion
>>> that 'remark' is the better option, except someone sees strong 
>>> reasons to ignore the prior art.
>>
>> “remark” is fine with me.
>
> Good. I will submit patches accordingly.
>
>>> 3) How to enable 'remarks'
>>>
>>> We need a way to enable 'remark' diagnostics. Quentin proposed to go
>>> for an approach similar to the warning flags. Where we control remarks
>>> with '-Rvector', '-Rloop-vector', ...
>>>
>>> I will read a little bit through the existing option system to 
>>> better understand what it is doing, possibly adding documentation / 
>>> cleanups on my way. I will come back with a proposal here.
>>
>> It’s a bit odd, but since these are diagnostics, why not use the 
>> existing -W flags?  You should be able to -Werror one of these, 
>> control them with #pragma clang diagnostics, etc.  It doesn’t seem 
>> like we need more complexity in this space.
>
> Good point. I will prepare the above patches such that they reuse the 
> existing infrastructure. If we really see a need for further 
> adjustments, we can do this incrementally.

Yes, this is sounding good. Keep in mind that it may be preferable not 
to permit upgrading remarks to errors (another potential use case of 
this being informational diagnostics about system headers that aren't 
user-actionable).

Alp.


>
> Cheers,
> Tobias
>

-- 
http://www.nuanti.com
the browser experts