[PATCH] Add back 'remark' to libclang interface

[Tobias Grosser]

On 28/04/2014 13:08, Alp Toker wrote:
>
> On 28/04/2014 11:11, Tobias Grosser wrote:
>>
>>
>> On 28/04/2014 11:16, Alp Toker wrote:
>>> CXDiagnostic with value 5 is higher than CXDiagnostic_Error and there
>>> are many applications using the outlined pattern that break following
>>> the change, either by crashing or mis-categorising diagnostics as fatal
>>> errors.
>>
>> I see that the above categorizes the diagnostic as an error. This is
>> obviously incorrect. Nevertheless, it should just cause an error
>> message. I do not see how/why this would crash.
>
> It hits an unreachable condition due to an unhandled case and crashes.

I consider this an application bug.

My quick look on ohloh did not find such usage. (Most results are 
duplicates of clang code, but e.g. ycm does the right thing and just 
maps to 'E' in case of unknown diagnostics). Obviously, there may still 
be other applications.

>> As remarks are _only_ emitted on user request and are promoted as tool
>> to understand the compilation, I would claim it is acceptable that
>> older tools not supporting remarks abort with an error. The user
>> should always be able to remove his '-Rpass=inline' option which the
>> tools does
>> not properly support anyway.
>
> Acceptable to whom?

Acceptable to me as a result of an application bug which is not even 
very likely to be triggered and which is caused by the use of a new 
feature not properly supported.

 > And for the first time we'd lose
> source-level and binary compatibility with the stable branch. That's not
> an appropriate change to make to a stable API.

We add values regularly to CXCursorKind and did so as well for 
CXAvailability_NotAccessible. Those changes have all been committed 
under the assumption that adding values do an enum does not break the API.

> I also think it's too early to add an accessor function. The remark
> feature hasn't yet settled down and could change significantly as the
> original review comments get addressed.
>
> Developers wanting access to the information can easily include the C++
> libclang headers if they feel the need to experiment. For everyone else,
> mapping to warning is very workable as a stopgap at this point in the
> 3.5 cycle.

In case there are still more general issues with the remark feature, I 
agree that we probably want to get those sorted out first.

I leave the comments above as information for later when we get back to 
the libclang interface.

Tobias