I tried to land changes in SVG code as part of https://bugs.webkit.org/show_bug.cgi?id=109044; they caused test failures, and I'm not sure why.
I'll find out and fix the problems in a smaller, more focused patch.
It looks like ExceptionCodePlaceholder doesn't do the right thing with the negation operator, which is upsetting to SVGLength::setValue, which has different behavior based on 'ec's value (http://trac.webkit.org/browser/trunk/Source/WebCore/svg/SVGLength.cpp?rev=142247#L213).
Ugh. Now I understand what ASSERT_NO_EXCEPTION is doing. It burns.
Off the top of my head, I have no idea how to make it behave in a way that would make `if (!ec)` work in debug. :( I will ponder.
So, as it turns out, this behavior is intentional: ASSERT_NO_EXCEPTION attempts to ensure that methods which care about the value of an ExceptionCode must initialize that ExceptionCode to 0 (see https://bugs.webkit.org/show_bug.cgi?id=78194). SVGLength::setValue does not.
Created attachment 187278 [details]
Hola, Jochen. Interested in reviewing this patch? :)
Comment on attachment 187278 [details]
View in context: https://bugs.webkit.org/attachment.cgi?id=187278&action=review
> + again with the latter. It does the same for 'ASSERT(ec == 0);' (and, as
I don't see wuch a change in the code?
(In reply to comment #6)
> (From update of attachment 187278 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=187278&action=review
> > Source/WebCore/ChangeLog:19
> > + again with the latter. It does the same for 'ASSERT(ec == 0);' (and, as
> I don't see wuch a change in the code?
The joys of copy/paste. I'll fix that. :)
Created attachment 187288 [details]
Patch for landing
Comment on attachment 187288 [details]
Patch for landing
Clearing flags on attachment: 187288
Committed r142261: <http://trac.webkit.org/changeset/142261>
All reviewed patches have been landed. Closing bug.