Community
Participate
Working Groups
Attached simple CDT C++ project shows, that if you try to navigate back and forth between the C function declaration and implementation using F3, it does only work from the .c file to the .h file, but not the other direction. For the C++ part, this works.
Created attachment 64859 [details] CDT C++ Project
Hi, This is not a issue in a C project which has all .c and .h files. This is a issue only in C++ projects containing .c files. The reason is PDOMCPPFunction is the binding given to function declarations in all .h files ( ieven if there is a corresponding .c file with same name). In such cases search in the index is returning null. Hence F3 is not working from .h to .c file but it works fine the otherway. Ravi
The underlying issue of this bug is that the AST computed for a header file does not use the language and scanner configuration of the source-file that includes the header. This is different to what we do in the indexer. There, headers are parsed in the context of a source file, if possible. The benefit of solving the more general issue is that all clients of the AST would work in the correct language (Content Assist, Open Call Hierarchy, Open Type Hierarchy and others). To make this happen, we have to change the way ITranslationUnit.getAST(..) and ITranslationUnit.getLanguage(..) work for header files.
(In reply to comment #3) > To make this happen, we have to change the way ITranslationUnit.getAST(..) and > ITranslationUnit.getLanguage(..) work for header files. There was a time when we used the project nature for that. I guess that's gone now...
(In reply to comment #4) > (In reply to comment #3) > > To make this happen, we have to change the way ITranslationUnit.getAST(..) and > > ITranslationUnit.getLanguage(..) work for header files. > There was a time when we used the project nature for that. I guess that's gone > now... That is still working. As stated in comment 2, we only have a problem if there is header file included by a plain-c source-file in a C++-project. The source file is parsed as plain-c. The indexer parses the header in the context of the source file, thus treats is as a plain-C file. However when the header is parsed as a translation unit on its own, it is treated as C++-file.
Added testcase: CPPSelectionTestsAnyIndexer.testCNavigationInCppProject_bug183973() I'll add an additional option that can be used with ITranslationUnit.getAST(...). With that other AST-clients are not affected. There is no immediate need to change ITranslationUnit.getLanguage(). The editor will use C++-syntax highlighting for the plain-c header file, which is usually not a problem.
Fixed as proposed in comment 6.
(In reply to comment #5) > That is still working. As stated in comment 2, we only have a problem if there > is header file included by a plain-c source-file in a C++-project. The source > file is parsed as plain-c. The indexer parses the header in the context of the > source file, thus treats is as a plain-C file. However when the header is > parsed as a translation unit on its own, it is treated as C++-file. I guess my point is that C functions, which would be C functions to be parsed properly by a plain C file, should be stored that way in the index. Any references to them from C++ files should link to the those CFunctions. I think this is a fundamental capability that we're missing from the DOM and it should really should start with how we handle extern "C". Even tougher would be cases like Ada or Fortran that can also link to C functions. Ideally we'd like open declaration to work properly there too (i.e. find the function definition in a C file, or an extern "C" function in a C++ file).
(In reply to comment #8) Ok, I see, at this point we don't handle references accross languages. That's a different problem, though.
