Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Codan: Index Updates for Referenced Projects
Re-appearing of marker on its own would be really magical. Something adds it back, so probably analysis is run again. There are different triggers to re-run analysis. Each
checker can be configured to be run on each or/and all of triggers, and user can configure if he wants these trigger to be run. There are also various trigger for indexer and user
settings to index or not (especially headers).
Also AST checkers work on unsaved code model where indexer is not get updated yet. So you have put breakpoints on indexer and your checker to figure out when and why it is running.

On Thu, Oct 30, 2014 at 11:52 AM, Corbat Thomas <tcorbat@xxxxxx> wrote:

Hi

 

I've observed strange behavior in my Codan checkers, and I failed so far to figure out the reason for this.

 

I've got a checker which should find undefined (class) types and marks them. Usually this checker works fine, but in an environment where I have two projects (A and B, where A references B) the checker does not get updated consistently. In my case I have a A.cpp file in project A referencing a B.h file from project B. In the .cpp file I have a variable declaration of type B. This type B is not defined:

 

//A.cpp in project A:

void foo() {

    B b;

}

 

//B.h in project B:

//empty

 

In this case my checker works and B in A.cpp gets marked.

When I update B.h as follows:

//B.h in project B:

struct B{};

 

I expect the Codan marker in A.cpp to vanish, but it does not. I can make it vanish by either rebuilding the index of A or by running "Run C/C++ Code Analysis" on A.cpp. When I do this the marker vanishes. So I expected the index used with A.cpp did not get the update.

 

Now the strange part:

When I revert the change in B.h, the codan marker reappears in A.cpp by itself (without explicitly rebuilding the index or running the analysis).

 

Does anybody have an idea why I can observe this asymmetric behavior?

 

Thanks for any input!

Thomas

 

PS: My checker works on ProblemBindings.


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top