Re: Proposal: use MOZ_LOG instead of NS_WARNING for spammy warnings about huge nscoord values

I didn't see any arguments against this change. Since this is the #1
ignored warning in the Gecko tree, with thousands of logs per test run,
let's silence it except for those actively debugging Layout size bugs.

Thanks,

--Jet

On Thu, Jun 4, 2015 at 11:33 AM, Daniel Holbert <[email protected]>
wrote:

> Per this thread...
>
> https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/Jw_4xdUTNnY
> ...some of the top culprits for NS_WARNING-spam are layout warnings for
> huge/unconstrained nscoord math.*
>
> I just talked with jet about this, and he suggested we use MOZ_LOG with
> an appropriate log-level, instead of NS_WARNING.
>
> I think this is a good idea.  That way, we layout hackers can configure
> our environments such that we always see these warnings (if we want to);
> meanwhile, our test-runners will have less spam in their logs, and other
> developers won't have to see these warnings gunking up their terminals
> needlessly, either.
>
> (The downside is, when you're diagnosing a test failure on treeherder,
> you might benefit from seeing these warnings; and you can't turn them on
> retroactively.  However, given the spamminess level of these warnings,
> and given that they're not for particularly flaky conditions [we're
> either doing math with these values or we arent'], I'm not sure they're
> really all that useful in this use case.)
>
> Thoughts?
> ~Daniel
>
>
> * specifically, the nscoord-related warnings that erahm reported as
> being in the top 40 are:
> {
> 65959 [NNNNN] WARNING: Overflowed nscoord_MAX in conversion to nscoord
> width: file ../../dist/include/nsRect.h, line 83
>
> 9201 [NNNNN] WARNING: have unconstrained width; this should only result
> from very large sizes, not attempts at intrinsic width calculation:
> 'psd->mIEnd != NS_UNCONSTRAINEDSIZE', file
> glayout/generic/nsLineLayout.cpp, line 884
>
> 9155 [NNNNN] WARNING: have unconstrained width; this should only result
> from very large sizes, not attempts at intrinsic width calculation:
> 'psd->mIEnd != NS_UNCONSTRAINEDSIZE', file
> glayout/generic/nsLineLayout.cpp, line 3058
>
> 9130 [NNNNN] WARNING: have unconstrained width; this should only result
> from very large sizes, not attempts at intrinsic width calculation:
> 'aISize != NS_UNCONSTRAINEDSIZE', file glayout/generic/nsLineLayout.cpp,
> line 160
>
> 4051 [NNNNN] WARNING: have unconstrained inline-size; this should only
> result from very large sizes, not attempts at intrinsic inline-size
> calculation: '(mFrameType == NS_CSS_FRAME_TYPE_INLINE &&
> !frame->IsFrameOfType(nsIFrame::eReplaced)) || type ==
> nsGkAtoms::textFrame || ComputedISize() != NS_UNCONSTRAINEDSIZE', file
> glayout/generic/nsHTMLReflowState.cpp, line 448
>
> 4050 [NNNNN] WARNING: have unconstrained inline-size; this should only
> result from very large sizes, not attempts at intrinsic inline-size
> calculation: 'AvailableISize() != NS_UNCONSTRAINEDSIZE', file
> glayout/generic/nsHTMLReflowState.cpp, line 360
>
> 3897 [NNNNN] WARNING: have unconstrained width; this should only result
> from very large sizes, not attempts at intrinsic width calculation:
> 'NS_UNCONSTRAINEDSIZE != aReflowState.ComputedISize()', file
> glayout/generic/nsBlockReflowState.cpp, line 118
>
> 3892 [NNNNN] WARNING: have unconstrained inline-size; this should only
> result from very large sizes, not attempts at intrinsic inline-size
> calculation: 'NS_UNCONSTRAINEDSIZE != computedISizeCBWM &&
> NS_UNCONSTRAINEDSIZE != availISizeCBWM', file
> glayout/generic/nsHTMLReflowState.cpp, line 2398
> }
> _______________________________________________
> dev-tech-layout mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-layout
>