[svn] 4305: Added an optimizer plugin facility to the GlobalOptimizer toolchain.

Question

Revision: 4305
Author: [email protected]
Date: 2008-12-15 07:37:19 -0800 (Mon, 15 Dec 2008)
Log Message:
Added an optimizer plugin facility to the GlobalOptimizer toolchain.
Refactored GlobalOptimizer.java, moved classes that
are relevant to plugins into their own source files.
Modified Paths:
flex/sdk/trunk/modules/asc/src/java/adobe/abc/AbcThunkGen.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/GlobalOptimizer.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/TraceManager.java
Added Paths:
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Block.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/CallGraph.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Edge.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Expr.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Handler.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Method.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Name.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Namespace.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Nsset.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/OptimizerConstants.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/OptimizerPlugin.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Type.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/TypeCache.java
flex/sdk/trunk/modules/asc/src/java/adobe/abc/Typeref.java

Answer 1

Andrew Gvozdev wrote:
> Normally findFileName() looks recursively through all files.
You're right, it is. This is probably a non-issue.
I was getting the file name from the error message, e.g.:
c:\projects\eclipse\Proj\mod1\util\micro\foo.c
I stripped off the path, and called findFileName with just the filename,
e.g.:
int i = fileName.lastIndexOf(java.io.File.separatorChar);
if (fileName.indexOf(projDir) != -1) {
fileName = fileName.substring(projDir.length());
IFile file = errorParserManager.findFileName(fileName);
This would find the file in errorParserManager's fFilesInProject map.
findFileName then calls the isPossibleMatch(IPath location, IPath
absoluteLocation) method, which in this example would be:
isPossibleMatch("foo.c", "c:/projects/eclipse/Proj/mod1/util/micro/foo.c");
Since "location" ("foo.c") is not absolutely, isPossibleMatch does:
int prefixLen = absoluteLocation.segmentCount() - location.segmentCount();
return prefixLen >= 0 &&
absoluteLocation.removeFirstSegments(prefixLen).equals(locat ion);
The problem is that removeFirstSegments intentionally does not remove the
device ID, so this comparison becomes:
"c:foo.c".equals("foo.c")
Since that is false, isPossibleMatch returns false, and the findFileName
returns null.
Now, that may be a bug. For non-absolute paths is seems like
isPossibleMatch should call a removeFirstSegments that also removes the
device ID. However, the solution for my error parser was to simply not
strip the path before calling findFileName. So now I do:
IFile file =
errorParserManager.findFileName("c:\projects\eclipse\Proj\mod1\util\micro\foo.c ");
findFileName strips the path itself before querying its map, but leaves
the path intact when calling isPossibleMatch. isPosibleMatch uses a
different check when its given an absolute location:
return location.equals(absoluteLocation);
This returns true, so findFileName returns the IFile resource from
fFilesInProject, and everything's OK.