Access FontCache global instance via singleton() static member function, as per coding style.
Created attachment 246773 [details] Patch
Created attachment 246780 [details] Patch
Created attachment 246781 [details] Patch
Comment on attachment 246781 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=246781&action=review We also need to update the Symbol Ordering Flags file Source/WebCore/WebCore.order. Did you intend to omit the list of changed functions from each ChangeLog entry? > Source/WebCore/platform/graphics/FontGlyphs.cpp:40 > + : m_cachedPrimaryFont(nullptr) Would it make sense to use in-class initialization for this instance variable? > Source/WebCore/platform/graphics/FontGlyphs.cpp:48 > + : m_cachedPrimaryFont(nullptr) Ditto.
Comment on attachment 246781 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=246781&action=review >> Source/WebCore/platform/graphics/FontGlyphs.cpp:40 >> + : m_cachedPrimaryFont(nullptr) > > Would it make sense to use in-class initialization for this instance variable? I don't know what's the policy for this. I like in-class initialization when this means we can get rid of the explicit constructor. However, if we need an explicit constructor, using also in-class initialization means we initialize members in 2 places.
(In reply to comment #4) > Comment on attachment 246781 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=246781&action=review > > We also need to update the Symbol Ordering Flags file > Source/WebCore/WebCore.order. Is this some very recent policy change? I was told not long ago that I should not update that file. > Did you intend to omit the list of changed > functions from each ChangeLog entry? Yes, I was told keeping them makes little sense unless you add per method changelogs.
Comment on attachment 246781 [details] Patch Clearing flags on attachment: 246781 Committed r180281: <http://trac.webkit.org/changeset/180281>
All reviewed patches have been landed. Closing bug.