| Re: [cdt-dev] Codan: Index Updates for Referenced Projects |
|
Update #2: I guess I figured out the difference regarding the index used between my automatically invoked (on type or open file in editor) checks and the
explicit run with "Run C/C++ Code Analysis". As described previously the first uses
AbstractASTIndexChecker.processModel, which works on an AST previously created in the reconciler. This AST is based on a project-only index (CModelBuilder2.parse).
Whereas the latter uses an AST created in CxxModelsCache, which is parsed using an index over all projects (CxxModelsCache.getIndex). I don't think either is correct. I guess my problem would be solved if CModelBuilder2 would consider at least the dependent projects too. For the
CxxModelsCache I would expect the indices of all related projects should be enough (depending and dependent). Out of curiosity I've had a look at the index the refactorings use. In CRefactoringContext.getIndex() they also acquire an index over all projects.
Any thoughts about the impacts if we changed the indices in these locations to contain the related projects only (which would be an extension in
the CModelBuilder2 case)? Regards Thomas From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Corbat Thomas Update: It seems the behavior I observed has more dependencies to the general context. Because I couldn't reproduce by observations below (which used to
be reproducible reliably for many tries), I extended my procedure. - Create projects A and B with files A and B, with dependency from A to B. - Add the reference to type B in file A (simple declaration). In File B type B does not exist yet! - Rebuild Index on project A. -> This obviously results in a ProblemBinding for type reference to B. - Run C/C++ Code Analysis on file A. -> The ProblemBinding still exists, of course. - Add the declaration of type B to file B - Switch to A -> The ProblemBinding still exists. (Checker ran) - Run C/C++ Code Analysis -> Marker (ProblemBinding) vanishes - Type in file A or switch out and in editor for A -> Marker reappears I furthermore figured out when rebuilding the index while the reference to type B is valid (no ProblemBinding), the ProblemBinding never occurs
for all the actions above after I remove the declaration of type B in file B. From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Corbat Thomas Thanks for the reply. My checker runs in both cases (when the marker reappears and when it does not), I've already checked that before. The triggers are actually not
my concern and the checkers are all executed when expected. My actual problem is that I could not figure out the significant difference between the two runs regarding the underlying index. In both cases the sequence of performing the changes in the other file
are the same (except for once it is deleting code and the other time is adding code). The changed file is saved afterwards and the FastIndexer is executed. The only difference I could observe so far (did not have much time though), was the entry function used if the checker is run on-typing (AbstractASTIndexChecker.processModel)
and when it is run explicitly (AbstractASTIndexChecker.processResource). For brevity my observations from my initial message in short: - File A has a reference to type B in file B; checker finds that reference and does not mark it. Deleting the type B in file B, saving B and opening
A in the editor: Marker appears (due to ProblemBinding of the reference). - File A has a reference to type B which does NOT exist in file B; checker marks reference (due to ProblemBinding). Adding the type B in file B,
saving B and opening A in the editor: Marker stays (the reference is still a ProblemBinding). Of course there is an include from A to B. - Running "Run C/C++ Code Analysis" in the case where the reference to B is marked by my checker although the type B exists: Marker vanishes. In all cases the files A and B are in different projects. I'm still confused why this exactly happens. Regards Thomas From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Alena Laskavaia 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 settings to index or not (especially headers). 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.
|