While writing some parserTests, I noticed that 1 + 1 === 2 evaluates to false! I still have to check, but I suspect operations are unnecessarily performed with float numbers, like it happened for edit_delta.
Oh wow, another weird discover: ladies and gentlemen, 1 / 2 === 0 is true!!! And so is e.g. 12 / 37, while integer division works well (36 / 12 === 3).
So, recapping, we treat integers as float when summing, and leave them as integers when dividing. Not bad.
From other parser tests I realized that the division behaviour is sort of intended: 5/2 === 2, 5. / 2 ===2.5. However, this isn't how it should work. Instead, it should be 5/2 === 2.5 and int(5/2) === 2, like anyone would expect.
There may be regressions from these patches. My suggestion is to run some queries to determine if there really is any risk. This should only affect uses of '===' and '!==' (type check) and of float numbers, leaving everything else unchanged. So basically those are the 3 things we should run queries for.
I decided for a different approach, i.e. use the same type as PHP. This leads to more uniform results and documentation. As for regressions: the main case here is when using triple compare operators like I was saying above, however there's an exception for the div/mul/mod patch: the result of division. Right now, 5/2 = 4 (this also contradicts the MW manual), which is highly undesirable. It'll produce a change in the value itself of the operation, so we may need to query usages of division.
My plan is not to have a plan :-) Jokes apart, I really can't see an easy way to analyse existing filters. Something to begin with could be to run a query for every use of triple-equality operators, since I don't think they're widespread in filters. Then, we need a separate query for divisions. Depending on the amount of data, we may then go on by either refining queries or fixing what is found.
Oh, and in case we won't be able to gather useful data from queries, then we'd need to add wfDebug to the changed functions so that they're only called if the result is different than before.
So... for the triple-check part, we can safely go with the following query:
select af_id from abuse_filter where af_pattern rlike '[!=]=='
I tried it on itwiki and got no results, and I believe there won't much neither in other wikis.
For the division part, we need a regex to only match slashes used for division. And to me, at the moment, it's not easy to think of a perfect, simple regex to do it without false positives.