Bug 131117 – Tidy up isIsolatedInline() and highestContainingIsolateWithinRoot()

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[David Kilzer (:ddkilzer)]

Tidy up isIsolatedInline() and highestContainingIsolateWithinRoot() based on review feedback for r166650.

<http://trac.webkit.org/changeset/166650>

[David Kilzer (:ddkilzer)]

Created attachment 228411 [details]
Patch v1

[Build Bot]

Comment on attachment 228411 [details]
Patch v1

Attachment 228411 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/6613225655238656

New failing tests:
transitions/cancel-transition.html

[Build Bot]

Created attachment 228425 [details]
Archive of layout-test-results from webkit-ews-01 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-01  Port: mac-mountainlion  Platform: Mac OS X 10.8.5

[Daniel Bates]

Comment on attachment 228411 [details]
Patch v1

View in context: https://bugs.webkit.org/attachment.cgi?id=228411&action=review

> Source/WebCore/rendering/InlineIterator.h:466
> +    for (RenderObject* root = iter.root(); object && object != root; object = object->parent()) {

This is OK as-is. Notice that |object| isn't modified outside of the for-loop, InlineIterator::{renderer, root}() are inline functions (since they are defined in the class definition) and that we can take advantage of the for-loop condition to handle the nullity check of |object| instead of performing an explicit nullity check on line 463. We can write the body of this function so as to read:

unsigned count = 0;
for (RenderObject* object = iter.renderer(), root = iter.root(); object && object != root; object = object->parent()) {
    if (isIsolatedInline(*object))
        ++count;
}
return count;

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> (From update of attachment 228411 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=228411&action=review
> 
> > Source/WebCore/rendering/InlineIterator.h:466
> > +    for (RenderObject* root = iter.root(); object && object != root; object = object->parent()) {
> 
> This is OK as-is. Notice that |object| isn't modified outside of the for-loop, InlineIterator::{renderer, root}() are inline functions (since they are defined in the class definition) and that we can take advantage of the for-loop condition to handle the nullity check of |object| instead of performing an explicit nullity check on line 463. We can write the body of this function so as to read:
> 
> unsigned count = 0;
> for (RenderObject* object = iter.renderer(), root = iter.root(); object && object != root; object = object->parent()) {
>     if (isIsolatedInline(*object))
>         ++count;
> }
> return count;

Nice!  Addressing these comments before landing.

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> for (RenderObject* object = iter.renderer(), root = iter.root(); object && object != root; object = object->parent()) {

This actually doesn't compile.  The reason is that the '*' operator only modifies |object| to be a pointer, while |root| is a RenderObject.

To make this work, we need to use a typedef:

    typedef RenderObject* RenderObjectPtr;
    for (RenderObjectPtr object = iter.renderer(), root = iter.root(); object && object != root; object = object->parent()) {

Is it still worth it?  Is declaring |object| and |root| in the same for() statement with the NULL check clearer than declaring |object| separately before the loop?  (I guess I should look at code gen as well since it's an inline method.)

[Daniel Bates]

(In reply to comment #6)
> (In reply to comment #4)
> > for (RenderObject* object = iter.renderer(), root = iter.root(); object && object != root; object = object->parent()) {
> 
> This actually doesn't compile.  The reason is that the '*' operator only modifies |object| to be a pointer, while |root| is a RenderObject.
> 

You're right!

> To make this work, we need to use a typedef:
> 
>     typedef RenderObject* RenderObjectPtr;

Or declare a temporary variable |root| outside of the for-loop.

>     for (RenderObjectPtr object = iter.renderer(), root = iter.root(); object && object != root; object = object->parent()) {
> 
> Is it still worth it?  Is declaring |object| and |root| in the same for() statement with the NULL check clearer than declaring |object| separately before the loop?  (I guess I should look at code gen as well since it's an inline method.)

My original motivation for suggesting the modification was to remove the extra nullity check and move the initialization of the variable |object| into the for-loop initialization towards making the for-loop more idiomatic. That is, resembling a for-loop for traversing the ancestors of a node. I don't have a strong opinion on such a change. I trust your judgement.

[David Kilzer (:ddkilzer)]

Committed r167447: <http://trac.webkit.org/changeset/167447>