[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