Thanks for the hint. I'll try to follow that road. Without examining it in detail, I recall that the reconciler (when saving B.h) also includes
A.cpp. But I'm not sure whether it updates it correctly for project A's index. Since rebuilding the index of project A explicitly (running rebuild index) fixes the problem, I guess this might be the way to go.
I'll send updates if I figure out anything else.
Regarding that topic. I'm struggling to find a proper place to create unit tests for this case. Is there any infrastructure for creating such tests?
Most core tests seem to be focused on a single project only.
Regards
Thomas
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sergey Prigogin
Sent: Mittwoch, 12. November 2014 04:08
To: CDT General developers list.
Subject: Re: [cdt-dev] Codan: Index Updates for Referenced Projects
On Mon, Nov 10, 2014 at 10:47 PM, Corbat Thomas <tcorbat@xxxxxx> wrote:
Sure. In Short File A is a source file and B is a header file.
Project A contains file A.cpp:
//A.cpp
#include "B.h"
B b{}; //Here I have a ProblemBinding on B.
Project B contains file B.h:
//B.h
//struct B{}; //This Definition is added.
There is a dependency from project A to project B.
Above we have the initial situation. The index is (re)built. Everything is as expected. Then I perform the following steps:
- Uncomment/Add the Definition of struct B in B.h.
-> Reconciler runs
- Open file A.cpp in Editor
-> This invokes Codan and my checker (through AbstractASTIndexChecker.processModel - with index over project A). My checker still sees a ProblemBinding for B.
Something is wrong here. Since B.h is included in A.cpp, it should be a part of A's index unless indexer itself uses compound index. The indexer doesn't seem to be using a compound index since PDOMUpdateTask.createDelegate(ICProject, IProgressMonitor)
calls PDOMManager.getIndex(ICProject), which creates an index for a single project.
Is #include "B.h" successfully resolved in the context of project A?
The behavior you observed could be triggered if the index of A is not updated properly when B.h is saved.
- Execute "Run C/C++ Code Analysis"
-> This invokes Codan and my checker (through AbstractASTIndexChecker.processResource - with index over all projects). My checker now sees the ICPPClassType of B.
- When start typing in the file A.cpp Codan runs again (with processModel).
- My checker again sees a ProblemBinding for B.
First, I'm not sure whether it makes sense to run the Codan checkers with different configurations. Second, what I actually would like to have an improvement for, is the
ProblemBinding after adding the required type.
Regards
Thomas
On Fri, Nov 7, 2014 at 2:30 AM, Corbat Thomas <tcorbat@xxxxxx> wrote:
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 don't quite understand the above description. Could you please explain which files are headers, and are source and what is included in what.
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.
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
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
_______________________________________________
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
_______________________________________________
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
|