Hi Connor,
On Jul 15, 2011, at 4:41 PM, Connor Wakamo wrote:
> I have another patch that I would like to submit for review. This patch adds
> two new API functions to libclang to return the container type (for member
> accesses, Objective-C message sends, etc.) for the current code completion
> context. Both functions take in a CXCodeCompleteResults to get the
> information that they return.
>
> The first function, clang_codeCompleteGetContainerTypeKind, returns a
> CXCursorKind for the container type. Additionally, it returns via a
> parameter whether or not Clang sees the container type as incomplete.
>
> The second function, clang_codeCompleteGetContainerTypeUSR, returns a
> CXString with the USR for the container type.
>
> Please let me know what changes I should make to my patch.
Index: include/clang-c/Index.h
===================================================================
--- include/clang-c/Index.h (revision 134754)
+++ include/clang-c/Index.h (working copy)
@@ -3133,6 +3133,39 @@
CINDEX_LINKAGE
unsigned long long clang_codeCompleteGetContexts(
CXCodeCompleteResults
*Results);
+
+/**
+ * \brief Returns the cursor kind for the container type for the current code
+ * completion context. The container type is only guaranteed to be set for
+ * contexts where a container type exists (i.e. member accesses or Objective-C
+ * message sends); if there is not a container type, this function will return
+ * CXCursor_InvalidCode.
+ *
+ * \param Results the code completion results to query
+ *
+ * \param IsIncomplete on return, this value will be false if Clang has
complete
+ * type information about the container type. If Clang does not have complete
+ * type information, this value will be true.
+ *
+ * \returns the container type kind, or CXCursor_InvalidCode if there is not a
+ * container type
+ */
+CINDEX_LINKAGE
+enum CXCursorKind clang_codeCompleteGetContainerTypeKind(
+ CXCodeCompleteResults
*Results,
+ unsigned
*IsIncomplete);
Despite the internal representation (which is, basically, broken), the
"container" of the code completion doesn't actually need a type, so I'd suggest
removing references to "type" from the API and its documentation. The
"container" could also be, for example, a C++ namespaces or the global scope,
e.g.,
namespace std {
template<typename T> class vector;
}
std::<complete here>
the "container" here is the namespace "std". The code completion itself will go
through Sema::CodeCompleteQualifiedId. It's okay not to update this particular
completion point to support namespace containers, but the API should be general
enough to support it.
+/**
+ * \brief Returns the USR for the container type for the current code
completion
+ * context. If there is not a container type for the current context, this
+ * function will return the empty string.
+ *
+ * \param Results the code completion results to query
+ *
+ * \returns the USR for the container type
+ */
+CINDEX_LINKAGE
+CXString clang_codeCompleteGetContainerTypeUSR(CXCodeCompleteResults *Results);
Again, this isn't just about types.
Is there any way to write tests for this functionality? Perhaps some additional
output in c-index-test giving the container and whether it's complete or not?
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
