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
clang_codeCompleteGetContexts_update2.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
