Jan 20 2020
Jan 9 2020
So, this problem is difficult if you want an accurate answer. For example, consider (page_namespace * page_namespace) + 1. This expression will always evaluate to a positive number (unless there's an integer overflow. I'm not sure if that could happen in PHP). But to see this you need to prove that x^2 + 1 is always positive which is really hard in general.
Jan 1 2020
A quick note: this is best done by pretty-printing the code from the AST. Avoid a bunch of ad-hoc regex replaces if possible.
Dec 31 2019
Gotcha. Yes, I agree with your diagnosis.
Dec 16 2019
Dec 6 2019
In AbuseFilter, it is indeed an array. E.g., I tried length(user_rights) === 42 in Special:AbuseFilter/test and edits of users with 42 rights come up.
Dec 2 2019
Dec 1 2019
I think this RFC is worth mentioning: https://meta.wikimedia.org/wiki/Requests_for_comment/Creating_abusefilter-manager_global_group. Note that there's no clear consensus on this issue.
Nov 30 2019
Perhaps something like this?
The goal of this request is to help other Abusefilter editors in various wikis to discover the system names. So while your proposed solution "works", I don't think it's satisfactory.
Nov 28 2019
My issue is resolved. I registered a new email in Gerrit (which could not be the email that I want, since the email that I want is already in the dropdown list. I simply can't change to it). After the registration, somehow I managed to make the system switch to my preferred email. So now it works!
@hashar I reloaded several times already (and just did it right now). It has no effect.
Nov 27 2019
Nov 21 2019
FWIW: PHP has pcre.backtrack_limit, so I don't think ReDoS is possible.
Nov 20 2019
Nov 19 2019
Ah, dup of T238464, though that task doesn't report the issue about bullet points.
Nov 17 2019
I misunderstood about how the confirmed group works, so let me write this part again:
@Daimona isn't it possible to merge the array specific functions right now (which should be completely backward-compatible, since it's a new feature). Then, ask global sysops to fix all filters in the "obvious" cases by changing in to the new features. For non-obvious case, obviously we should let local sysops handle them.
There are a couple of filters in various Wikimedia projects that currently have bugs due to this problem (e.g., https://cs.wikipedia.org/w/index.php?diff=17857577). Is there anything I can help to progress the above patch?
Nov 14 2019
Ah, I see. Closing as invalid then.
Nov 13 2019
@Daimona what about array and string? String will be tricky though because it could be "1.2" which should be converted to float.
Nov 12 2019
Nov 10 2019
Nov 7 2019
An X might be a good candidate, but I would leave the decision to the person who will address this issue.
@Daimona : also, timestamp % 0 currently passes Check Syntax. Does it make sense to include the fix in this patch too?
Nov 5 2019
It seems I used a wrong bug reporting form. Sorry :/
It seems I used a wrong bug reporting form. Sorry :/
To make it compatible with other boolean operation, i.e., ^, I think the better way should be to cast the result to a boolean. This is also great if one want to implement via re-interpretation of <a> & <b> as if <a> then (if <b> then true else false end) else false end.
I still do think it would be better if the grammar of the language doesn't need to know about tiny details of functions (that is, the ideal grammar should be stable, while it should be easy to add new functions). That said, I don't have strong opinion on this, so feel free to mark it as declined if you want.
Nov 4 2019
Here's one possible specification for it: it should be equivalent (or even rewrite) to
Well, the title is a little bit misleading actually. Commutativity would not be desirable if we want to return one of the operands, because
To avoid surprising users, I think we should mandate that index must be between 0 and |array| - 1.
Cool! Closing then.
Nov 1 2019
I totally agree with @Huji. Hoisting and undefined value can be very harmful. For instance:
Oct 31 2019
Actually, it should stay in that directory, which contains *everything* related to parsing (e.g. also data types, parsing exceptions etc.)
Oct 30 2019
Off-topic: AbuseFilterCachingParser should also really be called an interpreter or evaluator and moved outside of the parser directory... There's no parsing here.
I was led to believe that Thai Wikipedia was outdated because the syntax () is not valid in Wikipedias, but is valid in my local wiki. Now I see that this is intentionally disallowed in the new parser (https://phabricator.wikimedia.org/diffusion/EABF/browse/master/includes/parser/AFPTreeParser.php$554), which is a good thing IMO. Should we disallow () too in AbuseFilterParser for consistency?
May 8 2016
No, Amire80, this is not about i18n. It's about wiki markup parsing.
Apr 5 2016
My bad. Sorry :/
Feb 22 2016
Yes, it works! Thx :) Again, this should be documented...
Feb 21 2016
Also, the workaround doesn't work in Thai Wikipedia... We wish to block \bสุนัขไทยหลังอาน\.com, so we put \xe0\xb8\xaa\xe0\xb8\xb8\xe0\xb8\x99\xe0\xb8\xb1\xe0\xb8\x82\xe0\xb9\x84\xe0\xb8\x97\xe0\xb8\xa2\xe0\xb8\xab\xe0\xb8\xa5\xe0\xb8\xb1\xe0\xb8\x87\xe0\xb8\xad\xe0\xb8\xb2\xe0\xb8\x99\.com, but it's still not blocked...
Any update? The workaround and/or the /u should be documented too. People at meta don't even know that there's a problem with unicode characters (https://meta.wikimedia.org/w/index.php?title=Talk:Spam_blacklist#non-ascii_are_not_blocked.3F).