[cfe-commits] [PATCH] libclang: Exposing more statement, expression and declaration types.

[Douglas Gregor]

On Sep 29, 2011, at 12:28 AM, Manuel Holtgrewe wrote:

> Doug, thanks for your reply.
> 
> Hopefully, I hope that I addressed all of your points in the attached patch.

The patch looks generally fine, but you'll also need to update the test cases in test/Index (it's tedious, I know). A few minor comments:

+  /** \brief A predefined identifier such as __func__.
+   */
+  CXCursor_PredefinedExpr                = 106,

I don't think we want to expose this.

+  /** \brief This represents access to specific elements of a vector, and
+   * may occur on the left hand side or right hand side.
+   *
+   * For example the following is legal: "V.xy = V.zw" if V is a 4 element
+   * extended vector.
+   */
+  CXCursor_ExtVectorElementExpr          = 120,
+

ExtVectorElementExpr is a terrible name for a public API :(

+  /** \brief Represents a C99 designated initializer expression.
+   */
+  CXCursor_DesignatedInitExpr            = 122,

I'd rather not expose this at all, since a "designated initializer expression" isn't a notion that exists in C. 

+  /** \brief VAArgExpr, used for the builtin function __builtin_va_arg.
+   */
+  CXCursor_VAArgExpr                     = 123,

This is an implementation detail, and should not be exposed.

+  /** \brief Represents a C++ pseudo-destructor (C++ [expr.pseudo]).
+   */
+  CXCursor_CXXPseudoDestructorExpr       = 140,

Should this "just" be a member expression? The syntax is the same.


	- Doug

> Bests,
> Manuel
> 
> Am 29.09.2011 um 07:59 schrieb Douglas Gregor:
> 
>> Hello,
>> 
>> On Sep 28, 2011, at 7:38 AM, Holtgrewe, Manuel wrote:
>> 
>>> Dear all,
>>> 
>>> attached is a patch that exposes more statement, expression and declaration types through libclang. Also, I updated the Python bindings for these changes.
>>> 
>>> I have previously sent a patch but that has been overlooked so far. Thus, I resubmit another patch, this time with [PATCH] in the subject and hope that the missing [PATCH] was the reason  for why it was overlooked. If there are other requirements to be met before submitting patches then please tell me so.
>> 
>> 
>> Sorry I missed your first patch; traffic has been very high recently. Thanks for working on this!
>> 
>> The libclang API intentionally avoids exposing all of the expression kinds, because we want to be able to refactor Clang's internal representation freely without breaking the libclang API. So, it's fine to expose more cursor kinds for cursors that map unambiguously to a particular language element---say, an integer literal or a C++ "new" expression---but not to expose internal details (expression-with-cleanups, type trait expressions). A sampling of cursor kinds that I think should *not* be exposed: CXCursor_OffsetOfExpr, CXCursor_UnaryExprOrTypeTraitExpr, CXCursor_BinaryConditionalOperator, CXCursor_ImplicitCastExpr (debatable!), CXCursor_ImplicitValueInitExpr, CXCursor_ParenListExpr, CXCursor_ChooseExpr, CXCursor_CXXUuidofExpr, CXCursor_CXXDefaultArgExpr, CXCursor_CXXScalarValueInitExpr, CXCursor_UnresolvedLookupExpr (I'd rather it just be a declaration reference with no backing declaration), CXCursor_UnaryTypeTraitExpr, CXCursor_BinaryTypeTraitExpr, CXCursor_ArrayTypeTraitExpr, CXCursor_ExpressionTraitExpr, CXCursor_DependentScopeDeclRefExpr (same comment as for CXCursor_UnresolvedLookupExpr), CXCursor_CXXBindTemporaryExpr, CXCursor_ExprWithCleanups, CXCursor_CXXUnresolvedConstructExpr (one general "construct an object" expression would be better), CXCursor_CXXDependentScopeMemberExpr (just a member expression), CXCursor_UnresolvedMemberExpr (just a member expression), CXCursor_CXXNoexceptExpr (just a unary expression?), CXCursor_ObjCIsaExpr (just a member expression), CXCursor_ObjCIndirectCopyRestoreExpr, CXCursor_ShuffleVectorExpr, CXCursor_OpaqueValueExpr, CXCursor_AsTypeExpr, CXCursor_MaterializeTemporaryExpr.
>> 
>> 
>> Comment is wrong here:
>> 
>> +  /** \brief C++'s try statement.
>> +   */
>> +  CXCursor_SEHTryStmt                    = 226,
>> 
>> 
>> 
>> 	- Doug
> 
> -- 
> Manuel Holtgrewe			manuel.holtgrewe at fu-berlin.de
> Freie Universität Berlin		http://www.inf.fu-berlin.de/
> Institut für Informatik			Phone: +49 30 838 75246
> Takustraße 9				Algorithmic Bioinformatics
> 14195 Berlin				Room 021
> <libclang.diff>