Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Objective-C/C++ parser not generating "signature:" field for C functions #907
See the attached "foo.mm", which contains a static C function as well as an interface and implementation section for an Objective-C class. foo.mm.zip
cd to where the file is, and then run this command:
Then examine the resulting
The entry for
Note that the
Examine the generated tags again, and you'll see the expected entry for
I have a hack on the old Exuberant Ctags source, which "supports" Objective-C/C++ by routing through the C parser, and then following up with some lightweight parsing to find Objective-C structures. It's different enough from the current code that it's probably impractical to integrate, but the overall strategy (layering Objective-C/C++ support on top of the C/C++ parser) might be feasible anyway.
(About foo.mm.zip and tags.zip we want you to put them inline. I don't want to open zip.)
C++/C parsers completely rewritten by @pragmaware. As far as I can remember he started this work
Implementing ObjC parser based on the current C++/C parser looks natural for me because they really share their syntax. However, I'm not sure how @pragmaware will say about this.
If I am @pragmaware, I will say that I will accept reimplementing ObjC parser based on C++/C with following conditions:
Here are the referenced files inline:
Tags output for foo.mm:
Tags output for foo.cp:
This condition is not enough. vStringLength (parentName) > 0 is needed as additional condition.
I've been thinking a bit about this.
It's probably better to hack-in Objective-C support right into the new parser than doing a two pass analysis. Local variables, for instance, may appear both in C and Objective-C scopes. With two passes scoping will be just wrong.
I have done a couple of tests and it's rather feasible. However the C parser needs some refactoring before work on Objective-C can begin. The tag kinds are currently shared between C and C++ and I think they need to be split so, say, C enums are different from C++ enums and later Objective-C enums... (#977)
I think the approach you describe sounds reasonable.
As to enums, I'm not clear on what the issues are there. I know there's an "
It occurred to me that