Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338041

Summary:	Linked resource contains incorrect path in the ast
Product:	[Tools] CDT	Reporter:	Elena Laskavaia <elaskavaia.cdt>
Component:	cdt-parser	Assignee:	Project Inbox <cdt-parser-inbox>
Status:	RESOLVED WONTFIX	QA Contact:	Markus Schorn <mschorn.eclipse>
Severity:	normal
Priority:	P3	CC:	cdtdoug, eclipse.sprigogin, l.felber, malaperle
Version:	8.0
Target Milestone:	---
Hardware:	PC
OS:	Linux
Whiteboard:
Bug Depends on:
Bug Blocks:	337204

Description Elena Laskavaia

2011-02-23 21:36:44 EST

+++ 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

Comment 1 Elena Laskavaia

2011-02-23 21:37:09 EST

reverse block graph

Comment 2 Markus Schorn

2011-03-02 06:09:12 EST

(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.

Comment 3 Markus Schorn

2011-03-09 10:20:55 EST

I have updated the java-doc.

Comment 4 CDT Genie

2011-03-09 11:23:33 EST

*** 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

Comment 5 Lukas Felber

2011-03-10 02:25:37 EST

(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.

Comment 6 Markus Schorn

2011-03-10 03:55:42 EST

(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)