Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #337204 +++ Build Identifier: M20100909-0800 When linking a source folder D (containing file F.cpp) of a given project A into another project B and closing project A, codan tries to add markers to the file A/D/F.cpp instead of B/D/F.cpp. Reproducible: Always Steps to Reproduce: 1. create new project A and add a source folder D. Add new source file F.cpp to D (and enter some code). 2. create a new project B. Right-click on B and chose "New->Folder" (not "Source Folder") 3. check the "Advanced >>" button and chose "Link to alternative location (Linked Folder)". Browse to project A and select folder D. 4. right-click on project A and chose "Close Project". 5. opening file F.cpp in project A/D causes a ResourceException (trace bellow). The mistake causing the problem can be found in CodanCReconsiler.reconciled(...). The IWorkspaceRoot is used to findFilesForLocationURI, which returns 2 IFiles whereof the first one is chosen (which is the one located in the closed project A). A fix for the problem would actually be to loop over the returned files and check if the file's location matches the one location of the current AST. But this is not possible since the AST.getFilePath also (falsly) points to A/D/F.cpp instead of B/D/F.cpp. So the wrong AST location is probably the problem which should be solved fist. ---- This bug is created to issue in getFilePath (assuming author did a valid analysis) for ast location which would block fixing this in codan
reverse block graph
(In reply to comment #0) > But this is not possible since the AST.getFilePath also (falsly) points to > A/D/F.cpp instead of B/D/F.cpp. So the wrong AST location is probably the > problem which should be solved fist. The AST is unaware of eclipse projects, I'd be surprised if IASTTranslationUnit.getFilePath() returns anything different from the file-location: <location-of-project-A>/D/F.cpp The documentation of IASTTranslationUnit.getFilePath() is missleading.
I have updated the java-doc.
*** cdt cvs genie on behalf of mschorn *** Bug 338041: Updated java-doc. [*] IASTTranslationUnit.java 1.59 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core/parser/org/eclipse/cdt/core/dom/ast/IASTTranslationUnit.java?root=Tools_Project&r1=1.58&r2=1.59
(In reply to comment #2) > The AST is unaware of eclipse projects, I'd be surprised if > IASTTranslationUnit.getFilePath() returns anything different from the > file-location: <location-of-project-A>/D/F.cpp I think the problem is not caused by the AST returning the wrong path (it actually returns the path to <location-of-project-A>/D/F.cpp, whereas it should return <location-of-project-B>/D/F.cpp since the codan checker is hardly running on the file F in project A(which is closed) ). But the problem is caused that the AST is initialized with a wrong path, which comes form the LocationMap that gets the path form the CProcessor which then gets it form the FileContent. So if reconstructing the situation described above in comment #0, one should investigate what location is used when creating the AST. I assume that the string path which is given to the FileContent originates from an eclipse resource. And this resource is <location-of-project-A>/D/F.cpp instead of <location-of-project-B>/D/F.cpp.
(In reply to comment #5) > I think the problem is not caused by the AST returning the wrong path (it > actually returns the path to <location-of-project-A>/D/F.cpp, whereas it should > return <location-of-project-B>/D/F.cpp since the codan checker is hardly > running on the file F in project A(which is closed) ). > But the problem is caused that the AST is initialized with a wrong path, which > comes form the LocationMap that gets the path form the CProcessor which then > gets it form the FileContent. > So if reconstructing the situation described above in comment #0, one should > investigate what location is used when creating the AST. I assume that the > string path which is given to the FileContent originates from an eclipse > resource. And this resource is <location-of-project-A>/D/F.cpp instead of > <location-of-project-B>/D/F.cpp. Nope, the location is correct: It is <location-of-project-A>/D/F.cpp, because this location exists (in the file-system) independent of whether project A is open or not. The file <location-of-project-B>/D/F.cpp does not exist! (Because B/D is a linked folder)
