Skip to content
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

Merged
merged 1 commit into from
Jan 9, 2024
Merged

Conversation

dnkoutso
Copy link
Collaborator

@dnkoutso dnkoutso commented Jan 7, 2024

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.

@dnkoutso dnkoutso requested review from kdubb and lickel January 7, 2024 18:46
@@ -268,7 +268,7 @@ class FileSpecTests {

class Test {

let a: Array
let a: Swift.Array
Copy link
Collaborator Author

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"))

@dnkoutso dnkoutso force-pushed the always_qualify_duplicate_types branch from 1542b64 to 5ec895e Compare January 7, 2024 19:53
@@ -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>> {
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.

@dnkoutso dnkoutso merged commit 48094ac into main Jan 9, 2024
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants