Community
Participate
Working Groups
Build: Eclipse 3.1RC3, CDT M7, Exuberant CTags 544 Overview: In projects that use the CTags indexer both ctrl+click (hyperlink) and F3 (go to declaration) navigation seem to be broken. I have constructed a small test project that illustrates the problems, and provided it as an attachment. Details: 1) Load the supplied project. 2) Open mylib/func2.c and navigate to the myLibFuncTwo() declaration, try to ctrl+click on any of the following elements, notice that none of them work. This is odd, given that I've seen far larger examples work fine. L19: 'myHelper' --> function defined in the same file L18: 'SOME_MACRO' --> macro defined in header file L16: 'SomeStructure' --> type defined in another file (mylib.h) 3) Try the 'Open Declaration' option on the same test cases, a warning appears in the status bar in red text stating 'The operation is unavailable on the current selection (no name selected)'. 4) At L1 in mylib/func2.c notice that ctrl+click is only available for the '.h' portion of '#include "mylib.h"' and that it fails to navigate to the declaration. The outline in the projects view is correct, and works for navigation.
Created attachment 23751 [details] Simple C project with navigation problems Here is a simple C project that can be used to show navigation problems when using the CTags indexer.
FYI RC1 starts next Monday. Pls have these bugs fixed by then or moved off to a later milestone.
This is broken with both the CTags indexer and normal indexer. (I don't think that the indexer is involved at all). Here is a simple example that does not work int bar() { } int main() { bar(); } note that "All Declarations" of bar finds the correct field, but ctrl-click doesn't do anything. I am bumping the priorith and severity on this bug as this is a required workflow.
Fixed Dave's example. The original problem is caused by the DOM not being able to return a proper name for the selected element in the enclosed project. Specifically, the following always returns null: node = tu.selectNodeForLocation(tu.getFilePath(), offset, length);
Make sure that the project has the proper #include paths as well: - build the project to pick up cygwin includes for: #include <stdlib.h> #include <stdio.h> #include <string.h> - include jdk1.4.2_04/include and jdk1.4.2_04/include/win32 to pick up the includes for: #include "jni.h" The problem is with JNICALL. Without the #includes then the JNICALL causes IASTProblemDeclarations on the AST. With the proper #includes then the AST doesn't have IASTProblemDeclarations but the JNICALL is not kept on the AST (that is why there is the error "no name selected"). Also, with proper #includes setup in the project, the JNICALL breaks the offsets by 1 which can be seen when navigating through the DOM AST. So even with proper #includes, navigating on other elements in the AST fails because they have broken offsets.
There are a number things that need to be done to make this project sane: 1) Create a new Standard Make C project and import the source+folder enclosed 2) Add include paths + build 3) Change the SomeStruct to: typedef struct SomeStruct { int slot1; long slot2; } SomeStructure; 4) Notice that the offsets presented in the DOM Viewer are off by 1 for both func1.c and func2.c
Re: Comment #5: Notice that it is still broken even if you remove all of the JNI calls - ie. make all of them just regular functions.
Critical crashes, loss of data, severe memory leak (X) Major major loss of function
I thought it might help if I explained our use case. We're trying to use CDT to manage a large source-tree that targets about 20 different platforms, as such we'll almost never have the correct header files locally. This is the reason that the project include paths weren't set up. We were hoping that the CTags indexer would provide rudimentary search (better than grep) without the requirement of being able to compile locally.
The include paths are still used by the navigation features in order to determine what to navigate to/from. BTW, selection of the CTags indexer states that it provides only declaration symbols. Navigation to and from cross references will not work in this mode. There are 2 aspects to this bug. 1. If we do set up the project correctly there is some sort of error in the parser relating to offsets, which then messes up the navigation features. I can investigate this further and perhaps fix this for RC1. 2. Perhaps the selection/navigation features should have a backup strategy for when the translation unit cannot return a specific node relating to a selection. Devin, is it possible to query the index w/just a string in this case? I always thought that the CTags case could handle the "impossible to set up the include paths" scenario ... I'd like to see some more best effort heuristics in this case. This would not be able to be fixed for RC1 though ...
Without a proper AST the best that can be used to search against the index is the selected string i.e. "JNICALL", "foo". We need to discuss if this should be included in the F2/F3 heuristics which are supposed to "jump to the most correct element found". If the user wants to find all C/C++ elements in the index relative to a string then they can use Search to do this. Would plugging this functionality into F2/F3 be the best thing to do since only one result can be opened? I think that this wouldn't be helpful to the user as broken code could jump around to anything that is found in the index matching the string. Maybe the error returned to the user should hint that Search could be used to find matching results in the index?
We were looking for the same navigation features that one gets from CTags + VIM inside the Eclipse environment. For ambiguous definitions VIM simply displays a list of choices -- in practice, this works pretty well.
I've raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=101875 to track why the parser is failing for selecting these nodes. Graeme, as a work around to what you are doing, you can add a new line to the end of your header files. Devin wrote: > If the user wants to find all C/C++ elements in the index relative to a > string then they can use Search to do this. Would plugging this > functionality into F2/F3 be the best thing to do since only one result > can be opened? I do not want F2/F3 to bring up a dialog. I do want F2/F3 to take advantage of what is in the index in the case where the parser has a hard time figuring out the particular node selected. Consider this to be error-proofing your feature in the event of a parser bug (or misconfiguration). We already go to the first declaration when there are many in the index, I figure we can do the same in this case. Since in C there is very little overloading, I think this would work well. In C++ your mileage may vary. :-) Assigning to Devin, marking for 3.0 (should not gate RC1).
Created attachment 24107 [details] fix for this PR This patch adds the functionality that allows someone to perform F2/F3 on text even if there is nothing on the AST for that text (i.e. the AST is broken). Although it probably won't be addressed until after RC1. // example.cpp: int abc; int main(int argc, char **argv) { abc // this is an IASTProblemDeclaration but F2/F3 will find abc above // with this patch through the index }
I cannot read your patch. If you are attaching a zip file, pls don't say its a patch, as bugzilla tries to decode it as a text file.
Patch applied. This will be included in RC1. Thanks Devin.
Testcase testBug101287 is failing.
I have fixed the related testcase.
