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 > _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
