Description
PointerVariableConstraint
defined in ConstraintVariables.cpp
has a number of constructors that are used in different contexts, including a couple that build one from disparate parts. This makes refactoring code difficult, because we need to account for all the different input forms.
The largest problem is with ConstraintResolver.cpp
, which needs to create additional constraints without the context that was available in initial creation.
Determine if these new constraints must be created where they are, or if they could be created earlier with better context available. Find more standard input data that preserves itypes, generics, etc., like a decl type. Create a more useful copy constructor for use in ConstraintResolver.cpp
, saving original declarations if necessary.
Some uses of PVConstraint can be found:
ConstraintResolver:70
ConstraintResolver:118
ConstraintResolver:450
ConstraintResolver:508
ConstraintResolver:585
ConstraintResolver:694
TypeVariableAnalysis:108
Additionally the typedef that shortens the name to PVConstraint
reduces the ability of our IDE to use its default "Go to definition". If a refactor name change isn't too difficult, this would be a valuable debugging tool.