Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Rule idea: prevent broken capturing of lazy options in OptionsResolver smart defaults

Đang mở
  • Có gì không ổn?
#454 0 bình luận 1 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
php
Lĩnh vực
devtools, tooling

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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).

Ngôn ngữ chính
PHP
Star
806
Fork
105
Merge trung bình
1 giờ 55 phút
Pull request đã merge (30 ngày)
6

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của phpstan/phpstan-symfony

Tất cả issue của phpstan/phpstan-symfony

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.