You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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_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).
The text was updated successfully, but these errors were encountered:
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_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)
andtypeof(new String("b")) <: typeof(args)
.The text was updated successfully, but these errors were encountered: