Gets warning information from restbase and adds tracking categories
for deprecated chemical syntax.
Refactor mechanism to add tracking categories, and avoiding rechecking
already checked formulae.
Depends on: Ieca66f45ae7685d61eece1624bd7ff65ccad2eaa
Change-Id: I10e78ab79015dc1331f645c60b25bbbd237e23fe
Note that a class is not resolved this was. …::class is not a function
call. It's more like a named string constant. Technically still a
string. The advantage is that IDEs and tools like linters can much easier
understand that these strings refer to a class, and list them in usage
reports, renames, and such.
Change-Id: I5225543dbb837685a1840837cb2772dd576cca38
In T74240 support for LaTeX based rendering of the <math/>-tags was
removed. This change eliminates the unused code from the repository.
Bug: T195871
Change-Id: Ic57d83fa49f090b574ce8b82fd2ebc84a5350318
The motivation for this patch is to make the code less complex, better
readable, and less brittle.
Example:
public function onExampleHook( Parser &$parser, array &$result ) {
/* This is the hook handler */
}
In this example the $result array is meant to be manipulated by the
hook handler. Changes should become visible to the caller. Since PHP
passes arrays by value, the & is needed to make this possible.
But the & is misplaced in pretty much all cases where the parameter is
an object. The only reason we still see these & in many hook handlers
is historical: PHP 4 passed objects by value, which potentially caused
expensive cloning. This was prevented with the &.
Since PHP 5 objects are passed by reference. However, this did not
made the & entirely meaningless. Keeping the & means callees are
allowed to replace passed objects with new ones. The & makes it look
like a function might intentionally replace a passed object, which is
unintended and actually scary in cases like the Parser. Luckily all
Hooks::run I have seen so far ignore unintended out-values. So even if
a hook handler tries to do something bad like replacing the Parser
with a different one, this would not have an effect.
Removing the & does not remove the possibility to manipulate the
object. Changes done to public properties are still visible to the
caller.
Unfortunately these & cannot be removed from the callers as long as
there is a single callee expecting a reference. This patch reduces the
number of such problematic callees.
Change-Id: I21d53c989ea487607dc69e6b3365c023ef6729f5