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
I believe the issue is with MethodScanner and not ParameterScanner, as this is what is actually parsing the PHP tokens - it correctly ignores non-scalar type declarations such as array and callable. From what I can tell, string, int, bool and float are tokens of type T_STRING. As a result, the scanner believes they are classnames. This can result in classnames that simply don't exist.
I'm not really sure how this can be worked around inside the scanner. As far as I can tell, no PHP version checks are performed on the code being parsed, which means there's no reliable way of detecting whether or not string is an actual classname in PHP <7.0 code, or a scalar type declaration in PHP >=7.0 code.
Perhaps there needs to be some way to globally set the PHP version of the code being scanned?
It looks like there's a related issue with classes that have a leading namespace separator. MethodScanner doesn't appear to detect this, and fails to pass the token onto ParameterScanner. ParameterScanner then uses NameInformation to resolve the classname as if it is relative to the current namespace, rather than as an FQCN.
The issue is definitely with MethodScanner. If you create a completely separate instance of ParameterScanner and pass it just the tokens for a single parameter, including the leading T_NS_SEPARATOR token, it will correctly identify the FQCN, and NameInformation will correctly resolve it as an FQCN.
I've managed to create a patch to resolve the second issue, see #60. The original problem, incorrectly detecting scalar type declarations, is still an issue.
I believe the issue is with
MethodScanner
and notParameterScanner
, as this is what is actually parsing the PHP tokens - it correctly ignores non-scalar type declarations such asarray
andcallable
. From what I can tell,string
,int
,bool
andfloat
are tokens of typeT_STRING
. As a result, the scanner believes they are classnames. This can result in classnames that simply don't exist.I'm not really sure how this can be worked around inside the scanner. As far as I can tell, no PHP version checks are performed on the code being parsed, which means there's no reliable way of detecting whether or not
string
is an actual classname in PHP <7.0 code, or a scalar type declaration in PHP >=7.0 code.Perhaps there needs to be some way to globally set the PHP version of the code being scanned?
Originally posted by @djmattyg007 at zendframework/zend-code#56
The text was updated successfully, but these errors were encountered: