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
This is a meta-issue for a constraint solver rewrite for generic method inference to encompass #1585 and #1291. Right now, our solve() method to solve constraints has signature:
The returned Map is currently key'd on Elements corresponding to generic type variables. But as shown in Generic method inference does not support inferring different nullability for multiple calls to same generic method #1291, the same generic method may be invoked more than once in the context of a particular inference problem. So, really this should be key'd on some record datatype that includes both the Element and also the MethodInvocationTree identifying the call to the generic method.
Enhance generic method inference to compute mappings from type variables to full types? #1585 discusses how in various cases it would be better to infer a complete nullness-annotated type for each value in the map. Right now the values are InferredNullability, which only gives the top-level nullability of a type. Instead, the values in the map should be fully nullness-annotated Types, including nested annotations.
This may require other changes to the solver interface, e.g., addSubtypeConstraint may also need a MethodInvocationTree parameter to identify which call generated the constraint.
Clearly the internal vars map in ConstraintSolverImpl would have to change to track all this additional information. It too would also need to incorporate invocation trees into its keys and fully-annotated types into its values.
My hope is that with a fix here for #1585 we can remove some or all of the hacks from #1473 and #1574; I would hope that the entire NestedTypeVarSubstitutionRepairVisitor type and its related "repair" code could just go away.
Beyond keeping existing tests passing, the new test cases in #1291 and #1585 should also pass after the rewrite.
This is a meta-issue for a constraint solver rewrite for generic method inference to encompass #1585 and #1291. Right now, our
solve()method to solve constraints has signature:NullAway/nullaway/src/main/java/com/uber/nullaway/generics/ConstraintSolver.java
Line 78 in b35c8ca
This needs to change in (at least) two ways:
Mapis currently key'd onElements corresponding to generic type variables. But as shown in Generic method inference does not support inferring different nullability for multiple calls to same generic method #1291, the same generic method may be invoked more than once in the context of a particular inference problem. So, really this should be key'd on somerecorddatatype that includes both theElementand also theMethodInvocationTreeidentifying the call to the generic method.InferredNullability, which only gives the top-level nullability of a type. Instead, the values in the map should be fully nullness-annotatedTypes, including nested annotations.This may require other changes to the solver interface, e.g.,
addSubtypeConstraintmay also need aMethodInvocationTreeparameter to identify which call generated the constraint.Clearly the internal
varsmap inConstraintSolverImplwould have to change to track all this additional information. It too would also need to incorporate invocation trees into its keys and fully-annotated types into its values.My hope is that with a fix here for #1585 we can remove some or all of the hacks from #1473 and #1574; I would hope that the entire
NestedTypeVarSubstitutionRepairVisitortype and its related "repair" code could just go away.Beyond keeping existing tests passing, the new test cases in #1291 and #1585 should also pass after the rewrite.