You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 119d067
Browse filesBrowse the repository at this point in the historyBrowse files
Consume only the nullsafe twin's receiver from stored results instead of its whole subtree
- NodeScopeResolver::processExprNodeConsumingStored() now takes the node to
consume (the twin's receiver). The bool $consumeStoredExpressionResults flag
becomes ?Expr $consumeStoredExpression, and processExprNode() consumes a
stored result unconditionally only for that exact node. Everything else in
the plain MethodCall / PropertyFetch twin (arguments, a dynamic method or
property name) takes the normal path.
- Since #6765, later loop convergence passes are seeded with the previous
pass's stored results. The over-broad consume mode then answered the twin's
arguments from pass-1 results without walking them. Rules never saw those
nodes and gatherers never recorded them, so errors went missing and
property.onlyWritten was reported falsely.
- NullsafeMethodCallHandler / NullsafePropertyFetchHandler pass $expr->var
as the consumed node.
- ArgumentsHandler no longer consumes stored closure / arrow-function
argument results in consume mode (removed
NodeScopeResolver::isConsumingStoredExpressionResults()). Consume mode no
longer reaches arguments, and that branch was the same bug for closures in
`?->` arguments.
- Mirrored in turbo-ext (NodeScopeResolver.cpp, ArgumentsHandler.cpp,
Nullsafe*Handler.cpp, support.h, generated/NodeScopeResolver.h).
- Probed and covered: foreach/while/do-while/for, closure and arrow-function
arguments, a dynamic nullsafe property name, a dynamic nullsafe method name,
nested `?->` in arguments. Also checked chained `?->`, `??`/isset around
`?->`, spread and named arguments; all are fixed by the same change.
0 commit comments