Generate isHTML*Element() / toHTML*Element() helper functions

Generate isHTML*Element() / toHTML*Element() helper functions

Generate isHTML*Element() / toHTML*Element() helper functions using
html/HTMLTagNames.in as input. This avoids having to use macros to generate
these for each HTMLElement type. This is also safer because the generated
methods check the ContextFeatures and the RuntimeEnabledFeatures if needed.

The generated helpers are located in an HTMLElementTypeHelpers.h header that
is included in HTMLElement.h for convenience.

I am planning to use this header later on to make ElementTraversal more
powerful by letting the caller tell which type of Element (e.g.
HTMLTableRowElement) it wants to iterate on. It would look like:
ElementTraversal<HTMLTableRowElement>::next().

This is based on the following WebKit revision by <akling@apple.com>;:
http://trac.webkit.org/changeset/154965

R=
BUG=346095
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=167790

[Inactive, 2014-02-22 02:04:30]

I have only ported one file to the new isHTML*Element() helpers. I am planning
on taking care of the rest in a follow-up if this lands.

Here is what the generated header looks like:
http://pastebin.com/GQU9FJJK

[esprehn, 2014-02-22 02:46:36]

On 2014/02/22 02:04:30, Chris Dumez wrote:
> I have only ported one file to the new isHTML*Element() helpers. I am planning
> on taking care of the rest in a follow-up if this lands.
> 
> Here is what the generated header looks like:
> http://pastebin.com/GQU9FJJK

We tried auto generating these once, and then we went back to using macros.
What's different this time around? :)

[Inactive, 2014-02-22 02:58:44]

On 2014/02/22 02:46:36, esprehn wrote:
> On 2014/02/22 02:04:30, Chris Dumez wrote:
> > I have only ported one file to the new isHTML*Element() helpers. I am
planning
> > on taking care of the rest in a follow-up if this lands.
> > 
> > Here is what the generated header looks like:
> > http://pastebin.com/GQU9FJJK
> 
> We tried auto generating these once, and then we went back to using macros.
> What's different this time around? :)

Oh, I actually did not know that this was tried before. Why didn't it succeed?

I guess I could add the isHTML*Element() and the isElementOfType<>
specialization to the existing macro but it seems like this was worth
generating.

[Inactive, 2014-02-22 03:07:19]

On 2014/02/22 02:46:36, esprehn wrote:
> On 2014/02/22 02:04:30, Chris Dumez wrote:
> > I have only ported one file to the new isHTML*Element() helpers. I am
planning
> > on taking care of the rest in a follow-up if this lands.
> > 
> > Here is what the generated header looks like:
> > http://pastebin.com/GQU9FJJK
> 
> We tried auto generating these once, and then we went back to using macros.
> What's different this time around? :)

I know WebKit is generating the isHTML*Element() helpers and the
isElementOfType<> template specialization. I also know they stopped generating
the toHTML*Element() casting helpers and used macros for those instead. The
reason was that they had to use reinterpret_cast instead of static_cast because
the types were forward-declared and this is unsafe due to multiple inheritance.

However, I have addressed this issue in my patch. As you can see, I am using a
templated toElement<>() function for casting which does a static_cast (and not a
reinterpret_cast). I have toHTML*Element() macros that call
toElement<HTML*Element>() for compatibility with the existing code.

[esprehn, 2014-02-22 03:19:12]

lgtm, the HTMLObjectElement thing is kind of weird though.

https://codereview.chromium.org/175693007/diff/80001/Source/core/html/HTMLObj...
File Source/core/html/HTMLObjectElement.h (right):

https://codereview.chromium.org/175693007/diff/80001/Source/core/html/HTMLObj...
Source/core/html/HTMLObjectElement.h:117: inline const HTMLObjectElement*
HTMLObjectElement::fromFormAssociatedElement(const FormAssociatedElement*
element)
This is kind of weird. There's no way to keep the old casting function?

[Inactive, 2014-02-22 03:37:45]

https://codereview.chromium.org/175693007/diff/80001/Source/core/html/HTMLObj...
File Source/core/html/HTMLObjectElement.h (right):

https://codereview.chromium.org/175693007/diff/80001/Source/core/html/HTMLObj...
Source/core/html/HTMLObjectElement.h:117: inline const HTMLObjectElement*
HTMLObjectElement::fromFormAssociatedElement(const FormAssociatedElement*
element)
On 2014/02/22 03:19:13, esprehn wrote:
> This is kind of weird. There's no way to keep the old casting function?

It no longer works because there is no longer a toHTMLObjectElement() method to
overload. toHTMLObjectElement() is now a macro that calls the
toElement<HTMLObjectElement>() template specialization.

This fromFormAssociatedElement() is the best I could come up with so far but I
will think about it a bit more and see if I can get toHTMLObjectElement() to
work for this special case.

[Inactive, 2014-02-23 18:27:32]

https://codereview.chromium.org/175693007/diff/200001/Source/core/html/HTMLOb...
File Source/core/html/HTMLObjectElement.h (right):

https://codereview.chromium.org/175693007/diff/200001/Source/core/html/HTMLOb...
Source/core/html/HTMLObjectElement.h:116: template<typename T> inline const T&
toElement(const FormAssociatedElement&);
I made toHTMLObjectElement() accept a FormAssociatedElement as input instead of
a Node.

To do so, we are now overloading
template<typename T> inline const T& toElement(const Node&)
template<typename T> inline const T* toElement(const Node*)

instead of:
const HTMLObjectElement& toHTMLObjectElement(const Node&);
const HTMLObjectElement* toHTMLObjectElement(const Node*);

as toHTMLObjectElement is now a macro calling toElement<HTMLObjectElement>().

[Inactive, 2014-02-24 23:24:09]

The CQ bit was checked by ch.dumez@samsung.com

[Inactive, 2014-02-24 23:24:17]

The CQ bit was unchecked by ch.dumez@samsung.com

[commit-bot: I haz the power, 2014-02-24 23:24:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/175693007/200001

[Inactive, 2014-02-25 00:36:55]

Unless there is additional feedback, I am planning to land this tomorrow as my
next patch depends on this. Please speak up if you have feedback / concerns.

[Inactive, 2014-02-25 12:37:30]

The CQ bit was checked by ch.dumez@samsung.com

[commit-bot: I haz the power, 2014-02-25 12:37:55]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/175693007/200001

[commit-bot: I haz the power, 2014-02-25 13:32:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/ch.dumez@samsung.com/175693007/200001

[commit-bot: I haz the power, 2014-02-25 15:33:31]

Change committed as 167790