According to opprop/checker-framework#162, artificial trees are assigned with a fake "path" as if it's a child of the original AST. As a result, there's no corresponding AST path location for an artificial tree, as the following case shows
void foo() {
bar(new String("a"), new String("b"));
}
void bar(Object... args) {}
At the method invocation, a new-array tree is created as new Object[]{new String(), new String()}.
Since there's no corresponding AST path location for the artificial array creation, the current strategy is to create slots for the array primary type and component types on MISSING_LOCATION, which causes pain when debugging.
Alternative solutions to get rid of MISSING_LOCATION include:
(1) reusing existing AST paths for artificial trees
(2) not annotating the artificial trees during dataflow analysis, but in InferenceVisitor directly building constraints between method parameters and actual argument. Specifically for the above case, typeof(new String("a")) <: typeof(args) and typeof(new String("b")) <: typeof(args).
According to opprop/checker-framework#162, artificial trees are assigned with a fake "path" as if it's a child of the original AST. As a result, there's no corresponding AST path location for an artificial tree, as the following case shows
At the method invocation, a new-array tree is created as
new Object[]{new String(), new String()}.Since there's no corresponding AST path location for the artificial array creation, the current strategy is to create slots for the array primary type and component types on MISSING_LOCATION, which causes pain when debugging.
Alternative solutions to get rid of
MISSING_LOCATIONinclude:(1) reusing existing AST paths for artificial trees
(2) not annotating the artificial trees during dataflow analysis, but in
InferenceVisitordirectly building constraints between method parameters and actual argument. Specifically for the above case,typeof(new String("a")) <: typeof(args)andtypeof(new String("b")) <: typeof(args).