As reported in #672 and #729, the get_users() function also takes an array parameter which takes an 'exclude' key. That key is not our target, so should not be flagged.
This commit adds a hard-coded exception specifically for that situation.
If at a later point in time, more situations which need exceptions would be discovered, this solution can be made more flexible, but for now, there is no need (or insight into where the flexibility should be).
As the AbstractArrayAssignmentRestrictionsSniff::callback() method does not have access to the $stackPtr, the logic which can be used in the callback() is limited. Also see the review notes from upstream WordPress/WordPress-Coding-Standards#2266, which basically already pointed out this exact problem.
To get round this, I'm overloading the process_token() method to set a temporary $in_get_users property, which can then be read out in the callback() method to be used in the actual determination of whether the exception should be made or not.
As reported in #672 and #729, the
get_users()
function also takes an array parameter which takes an'exclude'
key. That key is not our target, so should not be flagged.This commit adds a hard-coded exception specifically for that situation.
If at a later point in time, more situations which need exceptions would be discovered, this solution can be made more flexible, but for now, there is no need (or insight into where the flexibility should be).
As the
AbstractArrayAssignmentRestrictionsSniff::callback()
method does not have access to the$stackPtr
, the logic which can be used in thecallback()
is limited. Also see the review notes from upstream WordPress/WordPress-Coding-Standards#2266, which basically already pointed out this exact problem.To get round this, I'm overloading the
process_token()
method to set a temporary$in_get_users
property, which can then be read out in thecallback()
method to be used in the actual determination of whether the exception should be made or not.Includes tests.
Fixes #672