Handle ::content and :host-context correctly in SelectorQuery.

Source/core/dom/SelectorQuery.h

Index: Source/core/dom/SelectorQuery.h
diff --git a/Source/core/dom/SelectorQuery.h b/Source/core/dom/SelectorQuery.h
index b0f99f139f4c07b1fd37872775dce29090cbc14c..e3abe921f2934bf2c57b5b71ecf7722c08b84f29 100644
--- a/Source/core/dom/SelectorQuery.h
+++ b/Source/core/dom/SelectorQuery.h
@@ -80,7 +80,8 @@ private:
     const CSSSelector* selectorForIdLookup(const CSSSelector&) const;
 
     Vector<const CSSSelector*> m_selectors;
-    bool m_crossesTreeBoundary;
+    bool m_crossesTreeBoundary : 1;
+    bool m_needsUpdatedDistribution : 1;

[kochi, 2015/05/25 05:40:57]

I'm not against this, or rather like this, but
I'm curious if there's a rule of thumb for Blink
where to use bitfields or not to use bitfields and use
booleans instead, as outside Blink.

I'm asking because you recently did the opposite:
https://codereview.chromium.org/1106183007
(not exactly opposite, but unbitfield'ized).

Is this because the 2 conditions in canUseFastQuery()

if (m_crossesTreeBoundary)
  return false;
if (m_needsUpdateDistribution)
  return false;

can be merged into one check (data & 0x03) != 0 by compiler?

[esprehn, 2015/05/25 06:21:11]

Those objects are on the stack, so using bitfields just means more bit masking
at runtime and we never get deep enough in the stack for the memory savings to
matter.

SelectorQuery objects are stored in the query cache on the heap so adding a new
member increases memory usage of the cache entries. Using a bitfield means no
memory increase.

[kochi, 2015/05/25 11:07:04]

Thanks for the explanation!

 };
 
 class SelectorQuery {