Php-cs-fixer: StaticLambdaFixer: skip known unfixable codeblock

[Slamdunk]

I tried @SpacePossum new StaticLambdaFixer #3187 but can't adopt it because I use Symfony Command::setCode() that dinamically binds closures to another object.
Example code:

// $foo = function() {}; // Original code now fixed
$foo = static function() {};

$foo = $foo->bindTo(new \stdClass);
// Warning: Cannot bind an instance to a static closure in /tmp.php on line 3

Would it be possible to integrate a comment annotation to ignore specific codeblocks?
Something like:

$foo = function() {}; // Fix this

// @PhpCsFixer::ignore{"static_lambda"}
$foo = function() {}; // Skip this

I just made the annotation up; we can borrow Doctrine's one.

[keradus]

from rule docs:

Risky rule: risky when using "->bindTo" on lambdas without referencing to $this.

[keradus]

currently, this is not possible to say that given line shall be ignored by given rules (or whole tool)

If you want to propose such feature, it would be interesting indeed.

[SpacePossum]

Root cause problem is that PHP does not provide a way to test if bindTo is possible, which would allow the SF code to test before trying to bind.
I'm not sure how to continue here, if the annotation logic is welcome here by the PHP-CS-Fixer community I'm interested in it as well of course :)

[Slamdunk]

After some days of thinking, a general purpose annotation for this functionality seems too much for such a little gain, considering also that the need didn't emerge before.

What about a fixer specific annotation, that would also declare why the fixer is skipped?
Something like:

// This will be fixed to static
$foo = function() {
    var_dump('foo');
};

// This will be skipped
$bar = function() {
    // @boundLambda
    var_dump('bar');
};

Easy to implement, it would impact only StaticLambdaFixer. WDYT?

[keradus]

What about a fixer specific annotation (...) it would impact only StaticLambdaFixer. WDYT?

That solution won't be accepted by me. Then, when one will need same functionality for other rule, he will recreate that solution. Then, user will want to do sth similar for other rule, and he will discover it's not working.
Either generic solution that will cover any rule, or none. Yes, it's bigger to implement, but it's not a hack.

[SpacePossum]

IMHO what would be nice on PSR-5 is a @ignore [some namespace]\[some detail]
Than all kinds of tooling good be notified that some violation should be ignored... than again the state of PSR-5 is maybe not in such a state to start introducing features like this...