FLEX-33311 CAUSE: It is possible for a call to ConstraintLayout.parseElementConstraints() to trigger, after a long series of other functions, a validation cycle on the same component whose layout is that ConstraintLayout instance. (If you want to see that series of stack traces, open stack.xml on the Jira ticket.) When this happens, either ConstraintLayout.measure() or ConstraintLayout.updateDisplayList() ends up calling clearConstraintCache(). (This is expected behaviour when there's no convoluted stack trace which ends up re-validating the same component, as we have here.) Now, when this inner validation cycle ends, and the outer call to parseConstraints() continues execution, it does so with all the cache variables nulled. This can result in a fatal if there is still a layout element remaining in parseConstraints() to parse via parseElementConstraints(). The latter function needs the cache Vector "rowBaselines", which is now null. SOLUTION: To cater for the special case when the call to parseConstraints() triggers another call to the same function, on the same ConstraintLayout instance, we use a counter to know when we're back in the outer call (when the counter is 0).
NOTES: -The unit test now passes. -Also removed an unused local variable.