Hi Loic, Seems like this was never committed in trunk? Any reason why? I have a project with a lot of anonymous struct and this patch would be useful.
On Thu, Feb 20, 2014 at 2:40 AM, Argyrios Kyrtzidis <[email protected]> wrote: > > On Feb 16, 2014, at 11:49 AM, Loïc Jaquemet <[email protected]> > wrote: > > >> > >> +/** > >> + * \brief Visitor invoked for each field found by a traversal. > >> + * > >> + * This visitor function will be invoked for each field found by > >> + * clang_visitCursorFields(). Its first argument is the cursor being > >> + * visited, its second argument is the client data provided to > >> + * clang_visitCursorFields(). > >> + * > >> + * The visitor should return one of the \c CXFieldVisitResult values > >> + * to direct clang_visitCursorFields(). > >> + */ > >> +typedef enum CXFieldVisitResult (*CXFieldVisitor)(CXCursor C, > >> + CXClientData > client_data); > >> > >> +CINDEX_LINKAGE unsigned clang_Type_visitFields(CXType T, > >> + CXFieldVisitor visitor, > >> + CXClientData > client_data); > >> > >> In general, the visitor is not recursing, right ? In that case why not > use a simpler "getNumFields / getField" pair of functions ? > > > > Well, the source code (AST.Decl.h ) exposes a iterator on its fields. > > Given that in other similar cases a visitor is used, I did the same. > > > > I did not want to introduce new code/new logic. > > I just want to expose the iterator. > > > > Do you want me to change it to a "getNumFields / getField" pair of > functions ? > > I see, the visitor interface is fine. > > > > > > >> +enum CXFieldVisitResult { > >> > >> Could you reuse CXVisitorResult instead of introducing a new enum ? > > > > Yes. I did not see that one. > > Will change that. > > After that, LGTM! > > > > > > >> > >> > >> On Feb 10, 2014, at 5:13 PM, Loïc Jaquemet <[email protected]> > wrote: > >> > >>> Hi, > >>> > >>> I'm pinging back about this patch : > >>> * libclang: Add three functions useful for dealing with anonymous > fields. > >>> +clang_Cursor_getOffsetOfField > >>> +clang_Cursor_isAnonymous > >>> +clang_Type_visitFields > >>> > >>> Currently, there is no function in libclang to access clang logic that > >>> handles anonymous members in a record. > >>> > >>> Given the current API , there is no direct method to : > >>> a) recover the offset of an anonymous field. > >>> - displayname == spelling == '', clang_Type_getOffset does not work > >>> + new clang_Cursor_getOffsetOfField will expose that information > >>> b) clearly identify that DECL as an anonymous record. > >>> + new clang_Cursor_isAnonymous will expose that information > >>> > >>> When using clang_visitChildren, an anonymous member will be returned > >>> as a STRUCT_DECL/UNION_DECL. > >>> Currently the libclang user has to re-implement the logic to > >>> differentiate FIELD_DECL in the list of children nodes > >>> For example, > >>> > >>> struct A { > >>> struct {int a;} typeanon; > >>> struct { > >>> int bariton; > >>> union { > >>> int foo; > >>> int foo2; > >>> }; > >>> }; > >>> int c; > >>> } ; > >>> > >>> Some children are STRUCT_DECL, some are FIELD_DECL, some are > attributes. > >>> Worse, > >>> children[0] == STRUCT_DECL (struct {int a;}) > >>> children[1] == FIELD_DECL (typeanon) > >>> children[2] == STRUCT_DECL (anonymous structure) > >>> children[3] == FIELD_DECL (int c) > >>> > >>> Sometime a STRUCT_DECL is a field (children[2]) sometimes it is just a > >>> STRUCT_DECL. > >>> > >>> The new function clang_Type_visitFields will expose the existing > >>> libclang capabilities to list only fields, and not all children node, > >>> as does clang_visitChildren. > >>> > >>> fields[0] == FIELD_DECL (first structure - typeanon) > >>> fields[1] == FIELD_DECL (second anonymous structure) > >>> fields[2] == FIELD_DECL (int c) > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Loïc Jaquemet > >>> <libclang-visit-fields.201116> > >> > > > > > > > > -- > > Loïc Jaquemet > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
