Change Details

While checking filter syntax (i.e. before saving a new filter, or anywhere else), edit variables are all set to null. This may sound like a natural choice, but can produce unwanted results. For instance, if I try to save a filter with ``` length(string(added_lines)) > 100 & 5 / length(string(added_lines)) > 2 ``` I get the error "abusefilter-exception-dividebyzero". This shouldn't happen for two reasons: first, because there's a condition right above on the length of added_lines (but I don't expect the parser to be so smart to understand it). Second, because even without the first condition this is not always guaranteed to be a division by zero. Probably it's not a good idea to save a filter with only the second condition, but I'm not sure if it's a good idea to completely prevent it. Note: arrays with variable length should also be allowed: the syntax check doesn't allow accessing an array element if such array is generated at runtime (for instance it is added_lines), although it makes sense to do so. To reproduce the problem you may try checking `added_lines[0]`, although that gives the wrong error (T198531).

While checking filter syntax (i.e. before saving a new filter, or anywhere else), edit variables are all set to null. This may sound like a natural choice, but can produce unwanted results. For instance, if I try to save a filter with ``` length(string(added_lines)) > 100 & 5 / length(string(added_lines)) > 2 ``` I get the error "abusefilter-exception-dividebyzero". This shouldn't happen for two reasons: first, because there's a condition right above on the length of added_lines (but I don't expect the parser to be so smart to understand it). Second, because even without the first condition this is not always guaranteed to be a division by zero. Probably it's not a good idea to save a filter with only the second condition, but I'm not sure if it's a good idea to completely prevent it. Note: arrays with variable length should also be allowed: the syntax check doesn't allow accessing an array element if such array is generated at runtime (for instance it is added_lines), although it makes sense to do so. To reproduce the problem you may try checking `added_lines[0]`, although that gives the wrong error (T198531). Solving this problem would also allow us to greatly simplify the [[https://phabricator.wikimedia.org/diffusion/EABF/browse/master/includes/parser/AbuseFilterParser.php$1063-1097|logic behind get_matches]], see comments in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/470987/.

While checking filter syntax (i.e. before saving a new filter, or anywhere else), edit variables are all set to null. This may sound like a natural choice, but can produce unwanted results. For instance, if I try to save a filter with ``` length(string(added_lines)) > 100 & 5 / length(string(added_lines)) > 2 ``` I get the error "abusefilter-exception-dividebyzero". This shouldn't happen for two reasons: first, because there's a condition right above on the length of added_lines (but I don't expect the parser to be so smart to understand it). Second, because even without the first condition this is not always guaranteed to be a division by zero. Probably it's not a good idea to save a filter with only the second condition, but I'm not sure if it's a good idea to completely prevent it. Note: arrays with variable length should also be allowed: the syntax check doesn't allow accessing an array element if such array is generated at runtime (for instance it is added_lines), although it makes sense to do so. To reproduce the problem you may try checking `added_lines[0]`, although that gives the wrong error (T198531). Solving this problem would also allow us to greatly simplify the [[https://phabricator.wikimedia.org/diffusion/EABF/browse/master/includes/parser/AbuseFilterParser.php$1063-1097|logic behind get_matches]], see comments in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/470987/.