| Re: [cdt-dev] ILinkage? |
|
Did you take a look at the LR C parser? Its not part of the CDT core, its in a separate source folder in the CVS repository named lrparser. It uses an LALR parser generator called LPG. I designed it because we needed to add support for the UPC language to CDT which is a simple extension of C99. The DOM C parser in CDT doesn't lend itself to be extended so instead of writing a UPC parser from scratch we decided to create an extensible C parser and then extend it to support UPC. The UPC plugins are also in the CDT repository and you can take a look at them to see how the parser is extended. We felt it was a more forward thinking approach and it would help others who want to extend CDT. It could be extended to support Objective-C in the same manner.
Yeah, objective c is a superset of c and that's why I was hoping to reuse/build upon what I could. However I'm still finding my way around the packages and wonder how much of the .internal. is going to get in the way, to the extent that I wonder if I'm going to have to reinvent the wheel in any case. Still, it's a good experiment and I'll submit what patches I can to try and move things along, but I can't see how I can easily extend the e.g. AbstractGNUSourceCodeParser or the KeywordSets if I needed to. And a bigger concern is that given the PDOM isn't extendable externally coupled with the fact that new types would be needed (protocols, selectors and so forth) that probably makes it unlikely that autocomplete would work without changes either. What did you do when writing UPC? Did you just end up forking or rewriting your own AST? Alex Sent from my (new) iPhone On 20 Feb 2009, at 21:20, Mike Kucera <mkucera@xxxxxxxxxx> wrote:
Alex, another thing you may want to consider from the parsing side is using the LR C parser as a base for Objective-C parsing. I used it as a base for writing the UPC parser. I skimmed the apple docs and they say that objective-c is fully compatible with C. So by reusing the LR C parser you get a nice chunk of functionality for free including parsing the C subset of the language and bindings to the CDT preprocessor. Its been designed so that extending it to support new syntax should be easy (in theory). This is just a thought worth considering, there may be good reasons to write a parser from scratch, I'm not sure. And of course the AST is a different story.... Mike Kucera Software Developer IBM Eclipse CDT Team mkucera@xxxxxxxxxx <graycol.gif>Alex Blewitt ---02/20/2009 03:38:27 PM---I'll file an enhancement but I thought the idea of doing objc dev outside of CDT HEAD was to avoid any objc references until su
I'll file an enhancement but I thought the idea of doing objc dev outside of CDT HEAD was to avoid any objc references until such time as it had built up momentum? A bigger concern, then, is what of the PDOM code which is all .internal. (including some interfaces). Aren't the ILinkage and PDOM fairly coupled? They appeared to be from my cursorary glancing. Alex Sent from my (new) iPhone On 20 Feb 2009, at 08:43, "Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx> wrote:
Please open an enhancement request for it. ILinkage is no longer marked as experimental in 6.0. I don't expect AbstractCLikeLanguage to change either. If you use it, we can also make it non-experimental (just open an enhancement request). Markus. From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alex Blewitt Sent: Friday, February 20, 2009 2:43 AM To: cdt-dev@xxxxxxxxxxx Subject: [cdt-dev] ILinkage? Importance: Low I'm starting to play around with the internals of CDT, and I've come across the following whilst creating a subclass of AbstractCLikeLanguage and the ILinkage that's referred to from it: AbstractCLikeLanguage: * <strong>EXPERIMENTAL</strong>. This class or interface has been added as * part of a work in progress. There is no guarantee that this API will work or * that it will remain the same. Please do not use this API without consulting * with the CDT team. * @since 5.0 ILinkage.java /** * Represents a linkage in the AST or the index. * <p> * <strong>EXPERIMENTAL</strong>. This class or interface has been added as * part of a work in progress. There is no guarantee that this API will * work or that it will remain the same. Please do not use this API without * consulting with the CDT team. * </p> * @since 4.0 */ This seems to be defined as the set {c,cpp,fortran} in the interface (and the implementing class is internal). How would I go about setting up a name for Objective-C, or can I simply return 'none' at this point? I'm somewhat playing in the dark to get a feel of how it fits together right now, but given that it had these in the comments I figured I'd do the honours. However, given that CDT is working on 5.1 (at least, that's the version it shows in Eclipse right now; 5.1.0.200902xxxx - will that be bumped to 6.0 later?) I was wondering how experimental these things are anyway ... Alex _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev _______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev |
