[Checkers] Various Notes Part 1: Framework

[Mahmood Ali]

Hi Mike et el,

In addition to Matt's topics, I wanted to share these notes that I  
collected in my case study.  I will revise them more and put them in a  
text file in the SVN soon.

Some implementation details and my surprises with Java Generics

1. An expression type may depend on the context it is in: generic type  
inference
Invocations to generic methods without explicitly (or implicitly)  
passing type parameters depend on the assignment context they are in.   
For example, Collections.emptyList() may have the following types:
   - List<String> in 'List<String> l = Collections.emptyList()'
   - List<@NonNull String> in 'List<@NonNull String> l =  
Collections.emptyList()'
   - List<Object> in 'Collections.emptyList();' (without assignment)
   - Iterable<Object> in 'Iterator<String> iter =  
Collections.emptyList().iterator()', which issues an error

: In our implementation the factory gets the assignment context from  
the TreePath object (specifies the path from the root compilation unit  
tree to the expression node) to get the assignment context and infer  
type parameter based on assigned to type.

==========================================
2. Type Parameters for a method invocation may be resolved based on  
type parameters without considering the assignment context.

Traditional java reports an error for the following:
	List<Object> l = Arrays.asList("s", "s1");
Our checker reports an error for the following:
	List<String> ls = Arrays.asList("interned string");

: We don't do anything about this

==========================================
3. Inferring types for conditional expressions is complex.
Let alone all the complexity of the specification found in JLS 15.25,  
the specification is more complex with type qualifiers.  Consider the  
following:
	List<String> rs = ...
	List<@Interned String> is = ...
	(randBool() ? rs : is).add(nonInternedString);   // this is not sound!
	@Interned String s = (randBool() ? rs : is);	// this is not sound  
either!

: I haven't implemented the right handler for this yet, but we have  
not experienced any bugs related to it yet
: The proper way is to simply specify the raw type as conditional  
expression type and issue a warning in such cases
: Lesson learned: Conditional expressions clauses should have the same  
conceptual type