[Checkers] Framework Change Request
Mahmood Ali
mahmood at MIT.EDU
Wed Apr 23 12:27:28 EDT 2008
Hi guys,
As I am reviewing the framework and saw the dependancies on
TreePath.getPath() function, I realized that in many cases we do want
the context of the assignment:
1. is l-value: this-mutable in Javari resolves as mutable as lvalue,
but readonly as rvalue
I noticed that Flow has a function to determine whether it's an
lvalue
2. self-type: need to figure out the most enclosing method and class
3. jdk-bug work-around: want to check whether a parameter is a catch
exception parameter or just a regular parameter.
4. type variable resolution: want to see what the assignment context is
5. default anotation: we want to get the nearest default annotation.
To address all of these issues, we have been using TreePath.getPath()
(or a variation of it). We stepped through hoops with VisitorState to
reduce such calls. However, the visitor already has the path (through
getCurrentPath()).
I am proposing (what Mike suggested sometime before) to supply that
expression context (through TreePath) to getAnnotatedType(), making
the signature of AnnotatedTypeFactory.getAnnotatedType(Tree) into
getAnnotatedType(TreePath). This makes out API closer to the Javac
Tree API, as it has Trees.getTypeMirror(TreePath path).
In the last time I ran the profiler, TreePath.getPath() was using
about 50% of time for nonnull checker because of default annotation.
Any suggestions?
- Mahmood
P.S. For the jdk-bug workaround, I made it check whether it is a catch
exception parameter only if the type is throwable which saved some
time, but the depenedancy on getPath() is still there.
More information about the checkers
mailing list