Re-allow in class with/by attributes

This bugfix release includes a better detection of disallowed attributes reallowed in a method with attributes (#304)

---

The original 4.3.0 release notes:

This release has been sponsored by @TicketSwap & @ruudk, thank you 🍰

Re-allow in class with/by attributes (#296, #298)

So far, when you wanted to re-allow a disallowed function or a method, or specifically disallow them, you could use:

• an allowIn path to specify a path or a filename where the function or method could be called without generating an error
• or allowInMethods (or the allowInFunctions alias) to specify functions and methods in which the disallowed function would be allowed
• you could also use the companion directives disallowIn or disallowInMethods (or the allowExceptIn[...] aliases) if you wanted to list paths or methods in which the call is explicitly disallowed

Starting with this release, you can use attributes to sort of mark functions and methods in which the disallowed call would be allowed (or explicitly disallowed):

• use allowInClassWithAttributes to allow for example a method in a class that has a specified class attribute
• use allowInMethodsWithAttributes (or the disallowInFunctionsWithAttributes alias) to allow the call in methods (or function) with the given method attribute (or a function attribute)
• use allowInClassWithMethodAttributes to allow a call in a class where any method has the attribute, where "any method" includes any other method as well, static or not, public, private, or protected
• you can also use the disallowIn[...] counterparts (with allowExceptIn[...] aliases) to specify only classes and methods in which the call should be disallowed

This allows you to create rules that do not depend on paths or method names, and can be useful if you're working with frameworks or libs that already use attributes. You can specify multiple items in the directives above and only one of them needs to match (it's not an AND list, more like OR list) and they all support fnmatch patterns.

Other minor changes

• More callable param tests for a bugfix in the previous release (#295)
• Call fnmatch less often only when needed (#297)
• Tweak attribute example in the disallowedAttributes docs (#299, thanks @ruudk)

---

You too can sponsor a release or buy me a 🍻 or a 🍰, thanks!

Re-allow in class with/by attributes

This release has been sponsored by @TicketSwap & @ruudk, thank you 🍰

Re-allow in class with/by attributes (#296, #298)

So far, when you wanted to re-allow a disallowed function or a method, or specifically disallow them, you could use:

• an allowIn path to specify a path or a filename where the function or method could be called without generating an error
• or allowInMethods (or the allowInFunctions alias) to specify functions and methods in which the disallowed function would be allowed
• you could also use the companion directives disallowIn or disallowInMethods (or the allowExceptIn[...] aliases) if you wanted to list paths or methods in which the call is explicitly disallowed

Starting with this release, you can use attributes to sort of mark functions and methods in which the disallowed call would be allowed (or explicitly disallowed):

• use allowInClassWithAttributes to allow for example a method in a class that has a specified class attribute
• use allowInMethodsWithAttributes (or the disallowInFunctionsWithAttributes alias) to allow the call in methods (or function) with the given method attribute (or a function attribute)
• use allowInClassWithMethodAttributes to allow a call in a class where any method has the attribute, where "any method" includes any other method as well, static or not, public, private, or protected
• you can also use the disallowIn[...] counterparts (with allowExceptIn[...] aliases) to specify only classes and methods in which the call should be disallowed

This allows you to create rules that do not depend on paths or method names, and can be useful if you're working with frameworks or libs that already use attributes. You can specify multiple items in the directives above and only one of them needs to match (it's not an AND list, more like OR list) and they all support fnmatch patterns.

Other minor changes

• More callable param tests for a bugfix in the previous release (#295)
• Call fnmatch less often only when needed (#297)
• Tweak attribute example in the disallowedAttributes docs (#299, thanks @ruudk)

---

You too can sponsor a release or buy me a 🍻 or a 🍰, thanks!

Callable param variant fix

What's Changed

• Check just one callable parameter variant (#293) this fixes a rather rare regression introduced in 4.1.1.

Can disallow `isset` & `unset`

What's new

• Can disallow isset() in disallowedFunctionCalls (#289, thanks @ksaveras!)
• Can disallow unset, too (#291)

Internal change

• array_merge arrays with error messages only when not empty, this should speed things up a bit, maybe (#287)

Detect callables and dynamic calls

This version replaces 4.1.0 in which callables were not detected in constructors. The notes below are taken from 4.1.0.

This release adds new detections listed below, meaning it's possible that you'll see new error messages.

First class callable syntax (#279), for example:

$func = print_r(...);

Dynamic calls (#276, #278), for example:

$func('foo');
$object->$method();

Test anonymous class usages (#277), for example:

$foo = new class implements ...
$foo = new class extends ...

Anonymous class usages (when the anonymous class extends DisallowedClass for example) were detected before, however the detection is now tested.

Detect callable parameters (#281, #283, #285), for example:

array_map('function', []);
array_map([$object, 'method'], []);
array_map([Class::class, 'staticMethod']);

Detect callables and dynamic calls (replaced by 4.1.1)

This release has been replaced by 4.1.1 which also detects callables in constructors, unlike this version.

Support both PHPStan 1.12 & 2.0

The 4.0 release removed support for PHPStan 1.x, and this release brings it back. Both PHPStan 1.12 and PHPStan 2.0 are supported (#273).

You can learn more about PHPStan 2.0 in the release notes or in the blog post and don't forget to get yourself an elephpant and a t-shirt!

Support & require PHPStan 2.0

This major release supports and requires PHPStan 2.0 (#267) (update: the 4.0.1 release adds back support for PHPStan 1.12)

As mentioned in the UPGRADING.md guide:

It's not feasible to try to support both PHPStan 1.x and PHPStan 2.x with the same extension code.

You can learn more about PHPStan 2.0 in the release notes or in the blog post and don't forget to get yourself an elephpant and a t-shirt!

Support PHP 8.4

• Support PHP 8.4 (#270)

That's it. That's the release.

Disallow create_function and support PHPStan 1.12.6, getting ready for 2.0

• Add create_function as a disallowed function call (#261, thanks @BackEndTea)
• Process ClassConstFetch where $class is Name only for enums to correctly support PHPStan 1.12.6 (#266)

Internal changes:

• Add phpstan/phpstan-deprecation-rules in expectation of PHPStan 2.0 (#263)
• Fix test class name (#260, spotted by @szepeviktor, thanks)