Prepare HTML5TreeBuilder for addition of new HTML5 parser code
Created attachment 56935 [details] Patch
Comment on attachment 56935 [details] Patch Please fix the below before landing. WebCore/html/HTML5Token.h:163 + ASSERT(!m_dataAsNameAtom); // An attempt to make sure this isn't called twice. I'm surprised this compiles. WebCore/html/HTML5TreeBuilder.cpp:87 + oldStyleToken.text = token.adoptDataAsStringImpl(); This breaks the abstraction. The client isn't supposed to know that characters() is backed by the m_data member variable. Also, we lost the ASSERT about the type of the token. WebCore/html/HTML5TreeBuilder.cpp:116 + for (size_t x = 0; x < characters.size(); x++) You should use an iterator here. WebCore/html/HTML5TreeBuilder.cpp:117 + processToken(token, characters[x]); Maybe processCharacter ?
(In reply to comment #2) > (From update of attachment 56935 [details]) > Please fix the below before landing. > > WebCore/html/HTML5Token.h:163 > + ASSERT(!m_dataAsNameAtom); // An attempt to make sure this isn't called twice. > I'm surprised this compiles. AtomicString has a String operator and String has a bool operator, by their powers combined we are captain planet. > WebCore/html/HTML5TreeBuilder.cpp:87 > + oldStyleToken.text = token.adoptDataAsStringImpl(); > This breaks the abstraction. The client isn't supposed to know that characters() is backed by the m_data member variable. Also, we lost the ASSERT about the type of the token. Fixed. Added "takeCharacters()" and "takeComment" with a FIXME to remove when we move off the old parser. > WebCore/html/HTML5TreeBuilder.cpp:116 > + for (size_t x = 0; x < characters.size(); x++) > You should use an iterator here. Fixed. > WebCore/html/HTML5TreeBuilder.cpp:117 > + processToken(token, characters[x]); > Maybe processCharacter ? Nah, this is intentional. All the tokens go through the same big switch statement.
Committed r60095: <http://trac.webkit.org/changeset/60095>
http://trac.webkit.org/changeset/60095 might have broken Chromium Linux Release
This broke the WIndows build due to "unreachable code" warnings. It’s been broken all day. What should we do?
Where "all day" == 75 minutes ago. :) Regardless, completely my fault. I'm committing a fix now. My apologies for the break.
(In reply to comment #6) > This broke the WIndows build due to "unreachable code" warnings. It’s been broken all day. What should we do? LOL, my mistake not all day. It was as far back as I could get on the waterfall so I thought it was longer than it was. I didn’t realize it was just a couple hours ago!
Committed r60108: <http://trac.webkit.org/changeset/60108>