Parser::firstCallInit() should just be done in the constructor (or, eventually, superclass constructor). We don't need lazy initialization of the Parser object anymore since the MediaWikiServices infrastructure handles lazy creation for us.
|Open||Goal||None||T248186 Prepare Parsoid for MediaWiki 1.35 LTS|
|Open||None||T236809 Refactor Parser.php to allow alternate parser (Parsoid)|
|Open||None||T236812 Parser.php should be split into a base class and a parser implementation|
|Open||None||T236811 Parser creation should always use factory|
|Open||None||T250444 Deprecate and remove Parser::firstCallInit()|
This patch is complete, but I think it could use review from the Performance-Team before being merged. From my ad hoc testing it appears that the parser is indeed lazily created and so this patch doesn't add performance cost, but I'd appreciate another pair of eyes and/or more tools brought to bear to ensure there's not some corner case where we're accidentally creating an unused parser object and slowing things down.
I did notice a few places that were creating Parser objects as a result of localizing messages through MessageCache::getParser(). That code path already always calls Parser::firstCallInit() so this patch wouldn't slow things down any -- however it's possible there are speedups possible if we can arrange that MessageCache::parse() isn't invoked where it's possible to avoid it.
The point of firstCallInit() is that it's not called from setHook(), so extensions calling $wgParser->setHook() from an extension function do not trigger firstCallInit(). CodeSearch shows that there are at least five extensions that are still doing that, none of them are used by WMF though. For example YetAnotherKeywords. We've had lazy-loading of Parser via StubObject for a long time -- the lack of lazy loading was not the reason for firstCallInit().
I think that usage has already been affected by the deprecation and removal of the global $wgParser, though (T160811). The reliable way to set a tag hook in modern MediaWiki is via the ParserFirstCallInit hook (which isn't going away), the way Extension:Poem does it, for example:
What am I missing?