Bug 1469649 Part 3 - Upgrade the assertion to MOZ_ASSERT, and update its comments. r=dholbert

The assertion is testing the sign of `availableFreeSpace` and `isUsingFlexGrow`.
After we use 64-bit arithmetic, it's likely that the stronger assertion holds.

Differential Revision: https://phabricator.services.mozilla.com/D123519
This commit is contained in:
Ting-Yu Lin 2021-08-25 06:43:34 +00:00
parent 1162baafb1
commit eb00182e36

View File

@ -3062,14 +3062,13 @@ void FlexLine::ResolveFlexibleLengths(nscoord aFlexContainerMainSize,
FLEX_LOG(" available free space = %" PRId64, availableFreeSpace.value);
// The sign of our free space should agree with the type of flexing
// (grow/shrink) that we're doing (except if we've had integer overflow;
// then, all bets are off). Any disagreement should've made us use the
// other type of flexing, or should've been resolved in FreezeItemsEarly.
// XXXdholbert If & when bug 765861 is fixed, we should upgrade this
// assertion to be fatal except in documents with enormous lengths.
NS_ASSERTION((isUsingFlexGrow && availableFreeSpace >= 0) ||
(!isUsingFlexGrow && availableFreeSpace <= 0),
"availableFreeSpace's sign should match isUsingFlexGrow");
// (grow/shrink) that we're doing (except if we've had integer overflow,
// which is unlikely given we've used 64-bit arithmetic). Any disagreement
// should've made us use the other type of flexing, or should've been
// resolved in FreezeItemsEarly.
MOZ_ASSERT((isUsingFlexGrow && availableFreeSpace >= 0) ||
(!isUsingFlexGrow && availableFreeSpace <= 0),
"availableFreeSpace's sign should match isUsingFlexGrow");
// If we have any free space available, give each flexible item a portion
// of availableFreeSpace.