[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