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

Bug 170386

Summary: Wrong gcc compile error reporting when conflict file names in a project
Product: [Tools] CDT Reporter: Rafal Somla <rsomla>
Component: cdt-buildAssignee: cdt-build-inbox <cdt-build-inbox>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: achapiro, eclipse.sprigogin
Version: 3.1.1   
Target Milestone: 5.0   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Rafal Somla CLA 2007-01-13 09:29:44 EST
Symptomps

After compilation using standard make C++ project errors reported by gcc and put inside "Problems" don't have correct paths detected so that it is not possible to click on them and show the offending line. This happens for some files  in the project but not for others. 

Analysis

After looking into the cdt.core code I discovered that this is due to having several files with the same name in different directories of a project. If an error was found inside bela/foo.c and there is also ala/foo.c in the project, then the error parser will be confused and will produce wrong File reference. This explains why the problem occurs only for some files, namely for those which have duplicates elsewhere in the workspace.

The GCCErrorParser creates File object from a file name using ErrorParserManager.findFileName method which uses a Map initialized by scanning all files in a workspace/project (not sure which scope). In case of duplicates only the first file is stored in the map. As file is searched using only its name (without a full path), the Map lookup can give wrong results.

Resolution

I created a patch which uses ErrorParseManager.fBaseDirectory member to get a full path of a file and use it to search for the offending file. Thus I added findFileInBaseDir method to ErrorParseManager:

	public IFile findFileInBaseDir(IPath filePath) {
		IPath path = fBaseDirectory;
		
		path = path.append(filePath);
		return (IFile) findFileInWorkspace(path);
	}

Then I changed ErrorPattern.recordError method to use this method when locating offending file:

                <cut>

		IFile file = null;
		if (fileName != null) {
			
			IPath fp = new Path(fileName);

			if( fp.isAbsolute() )
			{
				file = eoParser.findFilePath(fileName);
			} else {
		       file = eoParser.findFileInBaseDir(fp);
			}
			
		    if (file == null )
		    	file = eoParser.findFileName(fileName);
			
			if (file == null) {
				desc = fileName + " " + desc; //$NON-NLS-1$
			}
		}
		
Cheers!

Rafal
Comment 1 Andrew Gvozdev CLA 2008-08-18 17:30:36 EDT
looks like a dupe of bug 108489
Comment 2 Andrew Gvozdev CLA 2008-09-03 02:00:18 EDT
This problem was fixed with bug 208685.

Sergey, could you confirm and close this bug?
Comment 3 Sergey Prigogin CLA 2008-09-08 14:27:06 EDT
I believe this bug was fixed together with bug 208685. Rafal, please reopen if you still see the problem.
Comment 4 Sergey Prigogin CLA 2008-09-08 14:28:48 EDT
*** Bug 108489 has been marked as a duplicate of this bug. ***