Community
Participate
Working Groups
Build Identifier: There is a tight coupling between the CDT UI and the CDT's DOM parser http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core/parser/org/eclipse/cdt/internal/core/parser/?root=Tools_Project org.eclipse.cdt.internal.core.dom;x-friends:="org.eclipse.cdt.ui", org.eclipse.cdt.internal.core.dom.parser;x-friends:="org.eclipse.cdt.ui", org.eclipse.cdt.internal.core.dom.parser.c;x-friends:="org.eclipse.cdt.ui", org.eclipse.cdt.internal.core.dom.parser.cpp;x-friends:="org.eclipse.cdt.ui", org.eclipse.cdt.internal.core.dom.parser.cpp.semantics;x-friends:="org.eclipse.cdt.ui", This makes it more difficult to build a parser based upon C to be used outside of the CDT core package, unless warnings are ignored. Given that there isn't enough information in the IAST* subclasses to access required functionality directly, and the UI assumes that the IAST* nodes aren't being provided by a different implementation (there are casts to the underlying CAST* node) it is difficult to reuse these nodes for other C-like projects. The CPP nodes build upon the C nodes in the same plugin, and refactorings are done with both at the same time. Reproducible: Always
The coupling between the UI plugin and the core plugin is not as tight as your comment suggests. It is mostly because of reusing some utilities from internal core packages. Some of these could certainly be made API. You can always ask for that. Because we did not have a public way of creating AST nodes before CDT 7.0, the refactoring creates internal AST nodes. All of that could be changed now. However, there is a different reason why the implementation for the AST interfaces need to be part of CDT: Any implementation outside of CDT will stop us from making necessary changes (e.g.: evolving the AST to handle c++0x). Therefore the interfaces are marked as @noimplement. A support for another language can only be successful if the AST for that language is an integral part of CDT. (It does not really matter where the parser is implemented). After all you do want to have tooling on top of the AST and you want to reuse existing tooling. Therefore the tools need to able to use the AST of the language added. If you write your own tools, then you can do your own AST.
(In reply to comment #1) > However, there is a different reason why the implementation for the AST > interfaces need to be part of CDT: Any implementation outside of CDT will stop > us from making necessary changes (e.g.: evolving the AST to handle c++0x). > Therefore the interfaces are marked as @noimplement. Right, I understand that concern. But then you end up writing your own AST by copying and pasting code (as the Objective C project did) which then falls over in the face of evolving CDT versions. > A support for another language can only be successful if the AST for that > language is an integral part of CDT. (It does not really matter where the > parser is implemented). After all you do want to have tooling on top of the AST > and you want to reuse existing tooling. Therefore the tools need to able to use > the AST of the language added. If you write your own tools, then you can do > your own AST. If that is the ultimate position of CDT - that it's either languages that are in the CDT or you do everything yourself, then there is very little point in writing an external language that uses any of the CDT tools - you might as well re-write those yourself, too. If CDT is about being closed, then please close my suggestions on how to make CDT more extensible as WONTFIX.
