Bugzilla – Full Text Bug Listing
| Summary: | Doxygen: Documentation generator does not consider macros defined in a header | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | jean-daniel.perroset | ||||||
| Component: | cdt-editor | Assignee: | Project Inbox <cdt-editor-inbox> | ||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | Anton Leherbauer <aleherb+eclipse> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | d.kampert, eclipse.sprigogin, malaperle, stasik0, zeratul976 | ||||||
| Version: | 5.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
If the function cannot be parsed correctly, e.g. because of a syntax error, no Doxygen documentation can be generated. This is to be expected. (In reply to comment #1) > If the function cannot be parsed correctly, e.g. because of a syntax error, no > Doxygen documentation can be generated. This is to be expected. The function is totally correctly parsed by the compiler. If CLASS_NAME is not defined, after pre-processing the result will be int foo(int p1){ ... } The problem is only that comment generation doesn't take care about the preprocessing directives! (In reply to comment #2) > The function is totally correctly parsed by the compiler. If CLASS_NAME is not > defined, after pre-processing the result will be > > int foo(int p1){ > ... > } Are you sure? In my case the compiler complains: g++ -O0 -g3 -Wall -c -fmessage-length=0 -ob_main.o ..\b_main.cpp ..\b_main.cpp:26: error: `CLASS_NAME' does not name a type Something like this?
#ifndef TEST_H_
#define TEST_H_
class ClassName {
int foo(int a);
};
#define CLASSNAME ClassName::
#endif
#include "Test.h"
int CLASSNAME foo(int a)
{
}
(In reply to comment #4) Ok, thanks, that's a valid case. It seems the documentation generator creates the AST without index. Most probably to avoid any (b)locking issues. That's why it cannot detect the method definition properly. Created attachment 179164 [details] Doxygen auto edit use ast with index (In reply to comment #5) > (In reply to comment #4) > Ok, thanks, that's a valid case. > It seems the documentation generator creates the AST without index. Most > probably to avoid any (b)locking issues. That's why it cannot detect the > method definition properly. I think it's more desirable to wait for the index and have an accurate comment generated. Or is there an alternative? This patch simply adds the index to the existing getAST method. I also tried using ASTProvider.getASTProvider().runOnAST but it was much slower. The problem with this solution is that the AST is used without a lock on the index. This is OK as long as you don't resolve bindings, but this cannot be guaranteed since the class can be extended by clients and the index might be used by the AST itself. It might help to clear the index from the AST (IASTTranslationUnit.setIndex(null)), but I am not sure if this is sufficient to inhibit further access to the index. Another solution would be to not skip headers at all. This can increase parsing time a lot, but the resulting AST would be very accurate. Created attachment 183600 [details]
Doxygen auto edit use ast with index
I changed the patch so that the lock is released at the end of customizeDocumentCommand. A class overriding customizeDocumentCommand can still use getAST and get a non index based AST. If the extending class is overriding anything else, it will have access to an index based AST and the lock will be released. What do you think?
Comment on attachment 183600 [details]
Doxygen auto edit use ast with index
humm, bogus patch.
*** Bug 346642 has been marked as a duplicate of this bug. *** is any progress on this issue? This problem was fixed in bug 416247. I believe we can close this as a duplicate. Marked as duplicate. *** This bug has been marked as a duplicate of bug 416247 *** |
Build Identifier: I20070625-1500 If a function is declared for example as int CLASS_NAME foo(int p1){ ... } with CLASS_NAME either not defined or for example defined as CMyFoo:: then no Doxygen documentation is generated when adding /** above the function declaration. Reproducible: Always Steps to Reproduce: 1. Declare a function as int CLASS_NAME foo(int p1){} 2. In the corresponding .h file, declare #undef CLASS_NAME 3. Add /** above the function declaration