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