-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ContextFactory overwrites when multiple imports with same alias #11
Comments
@asgrim can this one be closed? It looks like you already provided a patch for this issue? |
In that case I will dive into this to see if it can be resolved |
Anything I can do to help here? |
Feel free to make a pr 😊 |
Seems reasonable aye 👍 it's a real edge case |
The issue here is that php is somehow interpreting files from top to bottom, we are simply parsing a file in the same way but are trying to map that in to an array. In the situation where you are requesting for a context for a specific namespace this won't work. But since all types that are resolved are somehow related to an Reflection type we should be able to have some way to figure out what is the correct context. If the user is still requesting a context for a namespace we could throw an exception. I do fully agree that this isn't a very easy and straightforward solution but it will work for the situations we have to handle in phpdocumentor. And I think this approach might work for BetterReflection as well? |
Assuming the API remains the same, nothing should need to change for us, we
pretty much just pass any type resolution to here anyway 👍
|
After some discussion with @nikic on https://github.com/phpDocumentor/TypeResolver/pull/9/files#r34962566 it looks like
ContextFactory::getNamespaceAliases()
doesn't cope with multiple imports with the same aliased name. For example:If you call
::getNamespaceAliases()
on this perfectly valid code, you'll see:This is not correct, but because it is keyed by the alias name, it is too much of a simple representation to allow multiple named aliases. It's maybe quite an edge case, but it does indeed appear to be a bug.
The text was updated successfully, but these errors were encountered: