(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
The change in CounterStyleManager::BuildCounterStyle converts a case-
insensitive comparison to a case-sensitive comparison by comparing atom
pointer directly. But this is fine because all names of builtin counter
styles should have been lowercased by the parser. For Gecko, it is done
in CSSParserImpl::ParseCounterStyleName, and for Servo, it is done in
counter_style::parse_counter_style_name.
MozReview-Commit-ID: JHHmzEaNIpn
Doing this at compile time would save a bit of our startup time, which
I've promised to do since @counter-style was initially implemented, see
bug 966166 comment 103 (the paragraph with "constexpr").
Also, having this implemented here makes using atom instead of string
on name of builtin counter styles easier, for later patches.
MozReview-Commit-ID: C9HYcuShBQv
Although this is not strictly necessary at the moment, static analysis
reports this as a new heap write hazard. Since we would eventually do
this change for symbols() support in Stylo, it is easier to just change
it here than convincing hazard analysis to believe it is harmless.
MozReview-Commit-ID: 7lfyZN6tDnJ
This change does the following:
* Introduce a new smart pointer called CounterStylePtr which either
holds an AnonymousCounterStyle strongly, or a named CounterStyle
managed by CounterStyleManager weakly, and use it to replace all
RefPtr<CounterStyle> around the codebase.
* Rename CounterStyleManager::mCacheTable to mStyles to reflect the
fact that it is used to manage all styles, not just for caching.
* Add a retired styles list which collect all named CounterStyle
evicted from mStyles, and post a PostRefreshObserver to destroy
objects in that list after next flush.
* Remove helper functions for counter style in nsStyleList and expose
mCounterStyle directly, to make code simpler with the new pointer.
Reason for adding a new smart pointer type rather than making their
AddRef/Release behave like BuiltinCounterStyle is that, it is possible
that after a flush, some stale style structs may still be alive. They
can contain pointer to destroyed CounterStyle objects. Although the
actual content may never be accessed anymore, RefPtr may still access
the object for refcounting during destruction.
MozReview-Commit-ID: xxegwSDhNb
