Remove some functions from class Node and make a few others non-virtual
Created attachment 70919 [details] Patch
Reported bug 47755 about the false positive style violation found in this patch.
Attachment 70919 [details] did not pass style-queue: Failed to run "['WebKitTools/Scripts/check-webkit-style']" exit_code: 1 WebCore/dom/Node.h:38: Code inside a namespace should not be indented. [whitespace/indent] [4] Total errors found: 1 in 9 files If any of these errors are false positives, please file a bug against check-webkit-style.
Attachment 70919 [details] did not build on chromium: Build output: http://queues.webkit.org/results/4478010
Comment on attachment 70919 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=70919&action=review r=me > WebCore/ChangeLog:62 > + (WebCore::enclosingInline): Moved function here from the Node class. Also > + fixed an incorrect cast this function did, which assumed the function > + result was always an element, which the function does not guarantee. Does this change observable behavior? > WebCore/dom/Node.h:370 > + // see @ref traversePreviousNode() Is there a reason to keep a part of this comment in Javadoc style?
Note the cr-linux redness. I think it's because of the FloatPoint.h include removed.
(In reply to comment #6) > Note the cr-linux redness. I think it's because of the FloatPoint.h include removed. I’ll add an include of MathExtras.h to HistoryItem.cpp to pick up the ceil function.
(In reply to comment #5) > > WebCore/ChangeLog:62 > > + (WebCore::enclosingInline): Moved function here from the Node class. Also > > + fixed an incorrect cast this function did, which assumed the function > > + result was always an element, which the function does not guarantee. > > Does this change observable behavior? I don’t think the incorrect cast had yet led to anything that would create incorrect code. I thought of it as a “ticking time bomb”, though. > > WebCore/dom/Node.h:370 > > + // see @ref traversePreviousNode() > > Is there a reason to keep a part of this comment in Javadoc style? I guess I could have gone further and tried to wipe out the half-baked attempt to use Javadoc style. I wasn’t sure whether I should.
Created attachment 71063 [details] Already-reviewed patch: Posted because it’s the only way to get the Early Warning System to test it
Attachment 71063 [details] did not pass style-queue: Failed to run "['WebKitTools/Scripts/check-webkit-style']" exit_code: 1 WebCore/dom/Node.h:38: Code inside a namespace should not be indented. [whitespace/indent] [4] Total errors found: 1 in 10 files If any of these errors are false positives, please file a bug against check-webkit-style.
> I guess I could have gone further and tried to wipe out the half-baked attempt to use Javadoc style. I wasn’t sure whether I should. It seems strange to keep them in comments that were modified (this may be the only one, in fact).
(In reply to comment #11) > > I guess I could have gone further and tried to wipe out the half-baked attempt to use Javadoc style. I wasn’t sure whether I should. > > It seems strange to keep them in comments that were modified (this may be the only one, in fact). Fixed now locally (although not in the patch I uploaded for the early warning system).
Committed r69987: <http://trac.webkit.org/changeset/69987>
Mass moving XML DOM bugs to the "DOM" Component.