-
Notifications
You must be signed in to change notification settings - Fork 27
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
Always qualify ambiguous types #110
Conversation
@@ -268,7 +268,7 @@ class FileSpecTests { | |||
|
|||
class Test { | |||
|
|||
let a: Array | |||
let a: Swift.Array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes sense because above we do:
.addProperty("a", typeName("Swift.Array"))
.addProperty("b", typeName("Foundation.Array"))
1542b64
to
5ec895e
Compare
@@ -443,7 +447,7 @@ internal class CodeWriter( | |||
/** | |||
* Returns the non-colliding importable types and module names for all referenced types. | |||
*/ | |||
private fun generateImports(): Pair<Map<String, DeclaredTypeName>, Set<String>> { | |||
private fun generateImports(): Pair<Map<String, List<DeclaredTypeName>>, Set<String>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be better to do the collision check inside and still only export the actually imported types? Rather than a list with possible collisions?
Not actually sure if that idea works.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmmm I will give it a shot! I see what you are suggesting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kdubb I attempted it and tried to use day with referencedTypeNames
but that broke a bunch of the tests.
I think this change gives me the most confidence given all tests pass and the ones that changed made sense ot me.
In this PR if we find ambiguous types we do not qualify them all. The test case was written against Foundation types which are almost always implicitly available so any file that was producing such output was successfully compiling.
A problem arises when the types that collide are not within Foundation system framework but rather some custom frameworks.
This logic here updates to always qualify them if there are more than one found for a given type.