Skip to content

Conversation

@dnkoutso
Copy link
Collaborator

@dnkoutso dnkoutso commented Oct 23, 2025

SwiftPoet would not emit fully qualified type name if it shared the same simple name of a different module. This would cause ambiguous compiler errors.

The actual fix is in SwiftPoet outfoxx/swiftpoet#123 so this PR adds a test case and bumps SwiftPoet.

Here's a screenshot of it failing here before the bump:

Screenshot 2025-10-23 at 5 11 44 PM

val nameToModules: Map<String, List<String>> = existingTypeModuleName
.entries
.groupBy({ it.key.simpleName }, { it.value })
.mapValues { it.value.distinct() }
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 change is irrelevant to the fix but it is correct so I sneaked it in.

extension DateTime : Proto2Codable {

public init(from protoReader: ProtoReader) throws {
var value: module_one.DateTime? = nil
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 is the line that is fixed with the SwiftPoet bump. Without it it emits var value: DateTime? = nil causing an ambiguous type error.

It now properly disambiguates it.

dependencies: ["Wire"],
path: "wire-tests-swift/no-manifest/src/main/swift"
),
.target(
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes make so our manifest test harness is built in Xcode to verify the compiler errors or successful builds.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would these work as testTargets instead so they aren't exported to everyone using Wire via SPM?

Copy link
Collaborator Author

@dnkoutso dnkoutso Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oooh good question. Yeah I can do that!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jszumski I dont think its possible actually. I cant have them depend on each other if they are testTargets according to SPM. Not sure if there is an SPM way to do this...

Seems like we are already doing this for the other target:

        .target(
            name: "WireTests",
            dependencies: ["Wire"],
            path: "wire-tests-swift/no-manifest/src/main/swift"
        ),

Copy link
Collaborator Author

@dnkoutso dnkoutso Oct 23, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does:

    products: [
        .library(
            name: "Wire",
            targets: ["Wire"]
        ),
    ],

only mean it exposes this target?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah actually I think that prevents my original concern 👍

@dnkoutso dnkoutso force-pushed the swift_ambiguation_bug branch from cb6c872 to c73bdb7 Compare October 23, 2025 14:16
@dnkoutso dnkoutso merged commit e182b9c into master Oct 23, 2025
15 checks passed
@dnkoutso dnkoutso deleted the swift_ambiguation_bug branch October 23, 2025 16:02
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.

3 participants