CSS Parser: Implement selector parsing [1/3]

CSS Parser: Implement selector parsing [1/3]

This patch begins implementation of CSS selector parsing with css-syntax
tokens. This adds support for basic selector constructors, leaving out
only attribute parsing and pseudo-element parsing. Most of the code for
handling namespaces and building the CSSParserSelector linked list is
taken directly from the BisonCSSParser.

This follows the grammar of CSS Selectors Level 4 (which isn't yet in
terms of the css-syntax). Unlike the Bison parser, I don't allow authors
to specify namespace prefixes without element names (e.g. ns|.class).

This code is not thread-safe as it uses CSSSelector, which requires
AtomicStrings.

http://dev.w3.org/csswg/selectors4/#grammar

BUG=330389
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=187202

[Timothy Loh, 2014-12-10 07:09:27]

timloh@chromium.org changed reviewers:
+ alancutter@chromium.org

[Timothy Loh, 2014-12-10 07:12:51]

Patchset #5 (id:80001) has been deleted

[Timothy Loh, 2014-12-10 07:22:03]

Patchset #5 (id:100001) has been deleted

[Timothy Loh, 2014-12-10 07:22:10]

Patchset #4 (id:60001) has been deleted

[Timothy Loh, 2014-12-10 07:22:14]

Patchset #3 (id:40001) has been deleted

[Timothy Loh, 2014-12-10 07:22:19]

Patchset #2 (id:20001) has been deleted

[Timothy Loh, 2014-12-10 07:29:54]

Whew, this is ready for review now. Including the next two patches, the only
remaining selector parsing logic is :nth-*(<an+b>) and :lang(<ident>), which a
low double-digit number of patches depend on (since we haven't wired up
stylesheet parsing, we only break usage in querySelector and similar).

A lot of the logic in this patch comes directly from CSSGrammar.y and
BisonCSSParser-in.cpp (with minor changes into using PassOwnPtr). Some of it
deals with pseudo-classes/elements, and so isn't relevant until part 3 is
landed, but since this is copied from the existing parser I think it's easier to
not split it off.

Part 2: https://codereview.chromium.org/747283003/
Part 3: https://codereview.chromium.org/792763003/

[Timothy Loh, 2014-12-14 23:53:02]

PTAL

[alancutter (OOO until 2018), 2014-12-15 13:52:59]

lgtm with nits, looking forward to this code getting proper testing.
It's a shame the selector parsing code is substantially more complicated than
the Bison grammar approach, I suppose one advantage to keep in mind in doing it
this way is the code is much less magical and possible to reason about.

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
File Source/core/css/parser/CSSParserValues.h (right):

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
Source/core/css/parser/CSSParserValues.h:238: void
setSelectorList(PassOwnPtr<CSSSelectorList>);
Where is this called?

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
File Source/core/css/parser/CSSSelectorParser.cpp (right):

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
Source/core/css/parser/CSSSelectorParser.cpp:20: if
(parser.m_tokenRange.atEnd())
Should this also check m_failedParsing as well?

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
Source/core/css/parser/CSSSelectorParser.cpp:35:
Vector<OwnPtr<CSSParserSelector> > selectorList;
No need for space between angle brackets.

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
Source/core/css/parser/CSSSelectorParser.cpp:345: }
RS that these are directly copied from the Bison parser. Hopefully producing
CSSSelectors directly will clean much of this old adjustment code up.

[Timothy Loh, 2014-12-15 23:43:04]

Cleaning up the actual selector building (e.g. moving away from
CSSParserSelectors) is months down the track, but once that time comes I'll see
if I can add some unit tests.

I'm not sure I'd say this is more complicated than the Bison approach. It's
probably harder to see at a glance what strings we actually allow when compared
to a parser generator, but on the other hand we
- removed the concept of floating selectors and floating selector vectors
- moved closer to the specification in language (compound selectors / etc.)
- have a much easier to follow order of operations (always left to right,
originally ltr for compound selectors and rtl for complex selectors), and have
the opportunity to restructure building up CSSSelectors

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
File Source/core/css/parser/CSSParserValues.h (right):

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
Source/core/css/parser/CSSParserValues.h:238: void
setSelectorList(PassOwnPtr<CSSSelectorList>);
On 2014/12/15 13:52:58, alancutter wrote:
> Where is this called?

Errr in part 3 of the patch for pseudo elements. I'll move the change to that
part.

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
File Source/core/css/parser/CSSSelectorParser.cpp (right):

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
Source/core/css/parser/CSSSelectorParser.cpp:20: if
(parser.m_tokenRange.atEnd())
On 2014/12/15 13:52:59, alancutter wrote:
> Should this also check m_failedParsing as well?

Not really, but I'll add an assert to make it clearer.

https://codereview.chromium.org/790593004/diff/120001/Source/core/css/parser/...
Source/core/css/parser/CSSSelectorParser.cpp:35:
Vector<OwnPtr<CSSParserSelector> > selectorList;
On 2014/12/15 13:52:59, alancutter wrote:
> No need for space between angle brackets.

Done.

[Timothy Loh, 2014-12-15 23:43:25]

The CQ bit was checked by timloh@chromium.org

[commit-bot: I haz the power, 2014-12-15 23:44:28]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/790593004/140001

[commit-bot: I haz the power, 2014-12-16 01:53:23]

Committed patchset #3 (id:140001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=187202