Add toHTMLTableCaptionElement() and toHTMLTableColElement(), and use them.

We'd like to avoid vanilla static_cast.

BUG=none
TEST=none; no behavior changes.

Review URL: https://chromiumcodereview.appspot.com/23894003

git-svn-id: svn://svn.chromium.org/blink/trunk@157264 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Fix perf regrssion caused by r155359

Move the logic for ending a failed provisional load back to
FrameLoader::checkLoadCompleteForThisFrame. I believe having it in 
receivedMainResourceError is slower because it allows the failed provisional
load callback to happen before the load event instead of after.

BUG=268777

Review URL: https://chromiumcodereview.appspot.com/23736005

git-svn-id: svn://svn.chromium.org/blink/trunk@157265 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Revert 157198 "Possible fix for a Mac performance regression."

> Possible fix for a Mac performance regression.
> 
> Introduced in
> http://src.chromium.org/viewvc/blink/trunk/Source/wtf/Vector.h?revision=157005
> 
> We now do the minimal amount of work possible on Vector destruction. We should
> now be faster than ever before:
> - The most common case is actually a totally unused Vector with no inline
> storage. In this case, we can bail and do no other work, if the buffer pointer
> is NULL.
> - There's no need to set m_size to 0 in the destructor; we've already checked
> that it is 0 and if not called resize(0) which will set it to 0.
> - In the Vector with inline storage case, we once again check m_size before
> calling shrink(), which might not be inline. It is common for m_size to be 0.
> 
> This also saves >50KB on a GCC Release build. clang, as usual, is barely
> affected on account of its less aggressive inlining.
> 
> 
> BUG=283760
> 
> Review URL: https://chromiumcodereview.appspot.com/23455034

TBR=cevans@chromium.org

Review URL: https://codereview.chromium.org/23475023

git-svn-id: svn://svn.chromium.org/blink/trunk@157266 bbb929c8-8fbe-4397-9dbb-9b2b20218538
Revert 157005 "Ensure that Vector destruction always clears the ..."

> Ensure that Vector destruction always clears the buffer pointer.
> 
> This was previously the case, with the exception of inline-buffer Vectors in
> "inline storage" mode.
> 
> In the process, some code cleanups were performed:
> - Removed unused releaseBuffer().
> - Added a little LIKELY / UNLIKELY.
> - Removed a lot of redundant branches.
> - Less work and two removed branches from the destructor path.
> 
> Saves 100KB from a GCC-compiled Chrome binary. No real difference on clang,
> which seems to inline very differently.
> 
> BUG=270545
> R=abarth@chromium.org, tsepez@chromium.org
> 
> Review URL: https://codereview.chromium.org/23531010

TBR=cevans@chromium.org

Review URL: https://codereview.chromium.org/23858004

git-svn-id: svn://svn.chromium.org/blink/trunk@157267 bbb929c8-8fbe-4397-9dbb-9b2b20218538