[cfe-dev] libclang interface for comments AST

Douglas Gregor dgregor at apple.com
Tue Jul 17 13:59:44 PDT 2012


On Jul 17, 2012, at 12:18 PM, Jacob Carlborg <doob at me.com> wrote:

> On 2012-07-17 18:45, Dmitri Gribenko wrote:
> 
>> I agree that it is easy to make up a string with an empty value.  But
>> what about clang_ParamCommandComment_getDirection, for example?  There
>> is no "neutral" parameter passing direction.
> 
> Just add a new member to the enum representing an invalid value. Just as 
> you've done with CXCommentKind. Call it 
> CXCommentParamPassDirection_Null, CXCommentParamPassDirection_Invalid or 
> something similar.
> 
> Another option, that always works, is to use an out parameter.
> 
> int clang_ParamCommandComment_getDirection(CXComment Comment, enum 
> CXCommentParamPassDirection* out);
> 
> Or the other way around:
> 
> enum CXCommentParamPassDirection 
> clang_ParamCommandComment_getDirection(CXComment Comment, int* success);
> 
> Although this doesn't really fit with the rest of the API.

Or simply default to CXCommentParamPassDirection_In and not worry about broken clients getting safe (but meaningless) information.

>> The API is inconsistent in itself: struct CXUnsavedFile, struct
>> CXVersion have members starting with uppercase letter, some other
>> structs use lowercase.  Of these two styles I followed general clang
>> style (which is a better thing to do).
>> 
>> Dmitri
>> 
> 
> These are the only structs that have names starting with uppercase:
> 
> CXCompletionResult
> CXCodeCompleteResults
> CXUnsavedFile
> CXVersion
> 
> BTW, it seems that libclang has its own style, which I see no problem 
> with since it's C not C++.


I think it makes sense to follow LLVM conventions going forward, even though some of the older structs in libclang don't follow those conventions.

	- Doug



More information about the cfe-dev mailing list