[PATCH] Add back 'remark' to libclang interface

Tobias Grosser tobias at grosser.es
Mon Apr 28 02:11:50 PDT 2014


Hi,

in commit 207319 the remark libclang interface was removed by Alp due to 
backward compatibility concerns.

The idea of this patch (and the identical original patch) is to expose 
'remark' Diagnostics in the libclang interface. Is it implemented by
adding a new diagnostics type to the libclang diagnostic enum (obviously 
not changing any existing enum values). This is the most straightforward 
implementation.

The concerns raised in the revert commit where:

   It trivially broke almost any stable application checking for
   Severity >= CXDiagnostic_Error or indeed any other kind of severity
   comparison upon encountering a 'remark'.

To not misunderstand this comment, if the user does not explicitly 
enable 'remarks', libclang based applications are _not_ broken and 
continue to work.

An issue may appear if both the user enables 'remark' diagnostics 
explicitly and an application assumes that the set of diagnostic
types does never change and, based on this assumption, contains code 
that checks the diagnostic type without handling unknown diagnostic 
types gracefully.

This can be seen as backward compatibility issue, but my personal
interpretation is that the application is relying here on undocumented
assumptions. As possible issues only manifest in case the user
explicitly requests remarks, I believe the proposed patch is fine.

Alp, what is the actual use case that would break? Do you have an 
application that relies on these assumptions? How likely is it that a 
user will enable remark diagnostics for this application?

Any comments?
Tobias

P.S: Alp apparently has a better solution. I let him explain this 
solution himself.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libclang-Add-back-CXDiagnostic_Remark.patch
Type: text/x-patch
Size: 3704 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140428/350ece84/attachment.bin>


More information about the cfe-commits mailing list