[cfe-commits] [PATCH] New libclang API function, clang_codeCompleteGetContexts

[Connor Wakamo]

I've made a few more changes, so let me know what else I need to do.

> If only Clang results are acceptable, I think the right way to handle this is to have no bits set. A client can always test for this and short-circuit its own search.
> 
> If Clang doesn't know what context it's in, then it should go ahead and set all of the bits, and the client will add everything it knows about. (This happens when parsing got confused).

OK, I've split this out now.  CXCompletionContext_Unexposed is a new constant representing a context with no bits set, indicating that only Clang results are acceptable.  I've changed CXCompletionContext_Unknown to now be a constant representing a context with all bits set, indicating Clang doesn't know what context it's in.

> I think it makes sense to provide ArrowMemberAccess and DotMemberAccess, since we also care about the answer to this question with C++ classes:

I've split MemberAccess into DotMemberAccess, ArrowMemberAccess, and ObjCPropertyAccess.

> Sure. Why not just call it CXCompletionContext_ClassTag, to match the others?

I've also changed the name of CXCompletionContext_ClassName to CXCompletionContext_ClassTag; I'm not quite sure why I didn't do that from the start.

> Hrm. I think we don't want NestedNameSpecifier here:
> 
> +    case CodeCompletionContext::CCC_Namespace: {
> +      contexts = CXCompletionContext_Namespace |
> +                 CXCompletionContext_NestedNameSpecifier;
> +      break;
> +    }

I've also removed NestedNameSpecifier from CCC_Namespace.

Thanks,
Connor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang_codeCompleteGetContexts_update2.patch
Type: application/octet-stream
Size: 35436 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110706/25339207/attachment.obj>