Rule idea: prevent broken capturing of lazy options in OptionsResolver smart defaults
还没有人认领这个 Issue。
评估
调研方向
Start by reviewing the PHPStan Symfony extension's handling of Symfony OptionsResolver smart-default closures and the immediate-versus-delayed callable distinction mentioned in the issue. Define how explicit and arrow-function captures should be detected while distinguishing OptionsResolver from Options, then verify that invalid delayed captures are reported and synchronous resolved-value captures remain accepted.
由索引模型根据 Issue 内容生成。
描述
symfony/options-resolver supports defining smart defaults that depend on the value of other options. This works by defining a default value using a Closure that has a first argument using Symfony\Component\OptionsResolver\Options as type (any other closure is just treated as being a normal default value for an option mean to contain a callable).
The object passed as this $options parameter (technically the OptionsResolver object itself, but this is an implementation detail) allows accessing options through ArrayAccess, but performs additional checks during those accesses to detect circular dependencies between options (where the default value of one option depends on another option, which tries to depend on the first one). This relies on synchronous access to those options in the callback implementing the default.
When defining a smart default involving a closure, a common mistake (which I caught in https://github.com/symfony/symfony/pull/61837#discussion_r2383077697, but I even did this mistake myself in the past) is to capture Options object in the closure and read those dependent options later rather than synchronously, breaking the cycle detection. The proper usage is to read the options synchronously and to capture only the resolved values in the closure.
It would be great if phpstan could detect such capturing of Symfony\Component\OptionsResolver\Options in closures (either through explicit use or through arrow functions) to prevent such issue, recommending to capture the resolved values themselves.
Due to the implementation detail that OptionsResolver passes itself as the Options object by implementing that interface instead of using a "friend" object, the rule must distinguish cases where we work with the OptionsResolver type vs cases where the only type we know is Symfony\Component\OptionsResolver\Options (only the later case should trigger the rule).
As phpstan implemented the distinction between immediately-invoked callables and delayed-invoked callables for parameters, the rule might be relaxed to accept cases where the closure is invoked immediately (as that will still perform synchronous read of the resolved option value).
- 主要语言
- PHP
- 星标
- 806
- 派生
- 107
- 平均合并
- 1 小时 55 分钟
- 30 天内合并 PR
- 6
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
phpstan/phpstan-symfony 的其他 Issue
-
`ParameterBag::keys()` stub not applied for Symfony ≥ 7.4 → false-positive `is_string()` `alwaysNarrowedType`可能已有人在做 @ChrisAbner 于 5 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
phpstan/phpstan-symfony#510 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
phpstan/phpstan-symfony#494 · 5 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 65/100
phpstan/phpstan-symfony#268 ·
-
Account for `\ErrorException` from `unserialize()` when Symfony’s PHP error conversion is enabled未关闭
难度 3/5 1-2 天 新手友好度 45/100
phpstan/phpstan-symfony#514 · 2 条评论 ·
-
难度 5/5 一周以上 新手友好度 35/100
phpstan/phpstan-symfony#509 · 2 条评论 ·
查看 phpstan/phpstan-symfony 的全部 Issue
相似的 Issue
-
mobile-app
难度 2/5 1-3 小时 新手友好度 74/100
Open-Locker/Open-Locker#352 ·
维护者通常 1 天内回复
-
[Bug]: SCIM Users groups[].value is returned as an integer, causing authentik user discovery to fail未关闭
难度 2/5 1-3 小时 新手友好度 62/100
grokability/snipe-it#20006 ·
维护者通常 1 天内回复
-
fixed
难度 2/5 1-3 小时 新手友好度 62/100
firefly-iii/firefly-iii#13150 · 2 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
TYPO3-Solr/ext-solr#4828 ·
维护者通常 5 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 3 天内回复