When allowExceptIn, allowExceptInMethods, or allowExceptInInstanceOf is combined with allowParamsInAllowed, a first-class callable like crc32(...) inside the disallowed location is incorrectly treated as allowed. The root cause is DisallowedCallsRuleErrors explicitly setting $args = null for first-class callables, and hasAllowedParams() returning true for null $args regardless of whether the calling context is an allowed zone (where that is reasonable) or a disallowed zone (where it is not). Without any allowParamsInAllowed condition the same callable in the same location is correctly disallowed, so adding a param restriction paradoxically makes the rule more permissive for first-class callables. The issue affects allowExceptInInstanceOf as well, which had param support before #414.
The failing test in #416 demonstrates the bug: crc32(...) inside methodA() (the except/disallowed zone) is not reported as an error, but it should be.
When
allowExceptIn,allowExceptInMethods, orallowExceptInInstanceOfis combined withallowParamsInAllowed, a first-class callable likecrc32(...)inside the disallowed location is incorrectly treated as allowed. The root cause isDisallowedCallsRuleErrorsexplicitly setting$args = nullfor first-class callables, andhasAllowedParams()returningtruefor null$argsregardless of whether the calling context is an allowed zone (where that is reasonable) or a disallowed zone (where it is not). Without anyallowParamsInAllowedcondition the same callable in the same location is correctly disallowed, so adding a param restriction paradoxically makes the rule more permissive for first-class callables. The issue affectsallowExceptInInstanceOfas well, which had param support before #414.The failing test in #416 demonstrates the bug:
crc32(...)insidemethodA()(the except/disallowed zone) is not reported as an error, but it should be.