Community
Participate
Working Groups
Build Identifier: Build id: I20100312-1448 The AST provided in the AbstractIndexAstChecker.processAst(IASTTranslationUnit ast) method is allways up to date (independent if active file was saved or not in the editor). The index however is not aware of the current (unsaved) state of the current file. This causes the indexer to yield IIndexInclude instances that are in real ony there anymore or the other way around. Reproducible: Always Steps to Reproduce: 1. create class that implements AbstractIndexAstChecker and add the xml code to plugin.xml so it implements a codan checker (or edit an existing checker) 2. execute: IIndexFile indexFile = index.getFile(ILinkage.CPP_LINKAGE_ID, IndexLocationFactory.getIFLExpensive(ast.getFileLocation().getFileName())); IIndexInclude[] includesToAdd = index.findIncludes(file); 3. create a source file which contains ony "#include <string>". 4. remove the include statement (without saving) -> this will cause the codan checker to trigger with an empty translation unit. -> 0 includes 5. the indexer will yield 1 include to <string>
I am not sure what you suggesting? AST is available for editor for unsaved changes, but indexer updates only on save. Not much I can about it.
Well I do understand why the situation is as it is now. It would be very nice if the indexer could not only be updated on file change, but also with the unsave file before codan checkers are triggered. Otherwise chodan checker can only be implemented reliably if they do not use the indexer at all. And considering static analysis the indexer is a very mighty tool which codan should be able to make (reliable) use of.
Sergey comment on the forum: "Although the index reflects the state of saved files only, it is possible to get ASTs for all dirty editors. When an index returns a file location corresponding to a dirty file, it should not be taken for the face value, but instead used as a trigger to do additional lookup in the AST of the corresponding dirty file. This is how the C/C++ Search works."
resolved as won't fix because nothing I can do about it. It had to be programmed in a certain way to avoid this issue.
