Compiler issue Xcode 11.4 swift 5.2 using Carthage

[afridikhalid]

What did you do?

Updated to Xcode 11.4 and run Carthage update iOS platform

What did you expect to happen?

Everything should work as intended

What happened instead?

Module compiled with Swift 5.1.2 cannot be imported by the Swift 5.2 compiler
I had opened an issue but someone has closed the issue without any fix

Charts Environment

**Charts version/Branch/Commit Number: 3.4.0
**Xcode version: 11.4
**Swift version: 5.2
**Platform(s) running Charts: iOS
macOS version running Xcode:

[liuxuan30]

Module compiled with Swift 5.1.2 cannot be imported by the Swift 5.2 compiler
you sure this is complaining Charts? As I suppose, we don't release a pre-built framework, so Charts should be built directly from source, hence there shouldn't be a 5.2 issue.

Can you post the full log?

[liuxuan30]

BTW I will check some PRs and perhaps merge a few and release a new version. That's on my todo list this week or next.

[afridikhalid]

Even with the new update it has not fixed the issue. still have the same problem

[liuxuan30]

I need some logs to understand. From my understanding, carthage will build from source, not from a prebuilt binary.

[gheatley]

I'm getting the exact same problem as @afridikhalid I'm using the latest Xcode 11.4.1

[gheatley]

Well, I seem to have found the cause of the problem;

If a module is built with BUILD_LIBRARIES_FOR_DISTRIBUTION and contains a public type with the same name as the module itself, clients will fail to import the module. (19481048) (FB5863238)
Workaround: Rename either the type or the module to remove the conflict.

So for my own curiosity, I tried this. I took the Charts project workspace and changed the target name to be different, eg: Chartz.framework and built the framework with Xcode 11.4.1. Brought that into my Xcode 11.4.1 project & bingo! You don't get that error anymore and everything works with Swift compiler 5.2.2.

I did not have to set the Build Libraries for Distribution to YES either in the Charts project. I seems the above Apple bug report is indeed correct. I'm not sure what it is that's clashing, but it seems there is a clash between the name of the framework & some component within the codebase itself.

[afridikhalid]

@gheatley @liuxuan30 I fixed the issue.
Remember if you are using Xcode as your version controller you can remove the local and re clone it.
then Carthage update will not work in my existing project I had to run
carthage update --no-use-binaries --platform iOS
which fixes the issue

[liuxuan30]

@afridikhalid so carthage maintain a binary of Charts on their side? I don't think they designed this way. we didn't provide a prebuilt binary for carthage. I might be wrong but I remember if carthage don't find an available binary, they will build from source. But you explictly add --no-use-binaries

[liuxuan30]

Well, I seem to have found the cause of the problem;

If a module is built with BUILD_LIBRARIES_FOR_DISTRIBUTION and contains a public type with the same name as the module itself, clients will fail to import the module. (19481048) (FB5863238)
Workaround: Rename either the type or the module to remove the conflict.

So for my own curiosity, I tried this. I took the Charts project workspace and changed the target name to be different, eg: Chartz.framework and built the framework with Xcode 11.4.1. Brought that into my Xcode 11.4.1 project & bingo! You don't get that error anymore and everything works with Swift compiler 5.2.2.

I did not have to set the Build Libraries for Distribution to YES either in the Charts project. I seems the above Apple bug report is indeed correct. I'm not sure what it is that's clashing, but it seems there is a clash between the name of the framework & some component within the codebase itself.

I checked our project, BUILD_LIBRARIES_FOR_DISTRIBUTION is set to NO. So I think this does not apply?

[gheatley]

Well, I seem to have found the cause of the problem;

If a module is built with BUILD_LIBRARIES_FOR_DISTRIBUTION and contains a public type with the same name as the module itself, clients will fail to import the module. (19481048) (FB5863238)
Workaround: Rename either the type or the module to remove the conflict.

So for my own curiosity, I tried this. I took the Charts project workspace and changed the target name to be different, eg: Chartz.framework and built the framework with Xcode 11.4.1. Brought that into my Xcode 11.4.1 project & bingo! You don't get that error anymore and everything works with Swift compiler 5.2.2.
I did not have to set the Build Libraries for Distribution to YES either in the Charts project. I seems the above Apple bug report is indeed correct. I'm not sure what it is that's clashing, but it seems there is a clash between the name of the framework & some component within the codebase itself.

I checked our project, BUILD_LIBRARIES_FOR_DISTRIBUTION is set to NO. So I think this does not apply?

Indeed your BUILD_LIBRARIES_FOR_DISTRIBUTION is set to NO. But what the bug report says there is not quite accurate, in that BUILD_LIBRARIES_FOR_DISTRIBUTION needs to be YES for this to apply. It does not need to be set to YES for this problem to affect Charts. The solution however, works!
Also @afridikhalid 's fix did not work for me at all.