Skip to content
This repository has been archived by the owner on Jan 29, 2020. It is now read-only.

Zend\Code\Scanner\MethodScanner does not account for scalar type declarations #56

Open
djmattyg007 opened this issue May 7, 2016 · 5 comments

Comments

@djmattyg007
Copy link
Contributor

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?

@djmattyg007
Copy link
Contributor Author

As an aside to this, it would be nice if ParameterScanner and MethodScanner were able to handle non-class type declarations of any form.

@djmattyg007
Copy link
Contributor Author

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.

@djmattyg007
Copy link
Contributor Author

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.

@djmattyg007
Copy link
Contributor Author

I had to re-submit the PR as #61.

@weierophinney
Copy link
Member

This repository has been closed and moved to laminas/laminas-code; a new issue has been opened at laminas/laminas-code#27.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants