[SR-13050] Error compiling .swiftinterface file

[swift-ci]

Previous ID	SR-13050
Radar	rdar://problem/51994654
Original Reporter	khose (JIRA User)
Type	Bug

Attachment: Download

Environment

MacOS Catalina 10.15.5 (19F101)

XCode 11.5 (11E608c)

Ruby 2.6.4

The attachment includes both the app project and the library project, including Gemfiles and Podfiles to fix versions as much as possible.

Additional Detail from JIRA

Votes	0
Component/s	Compiler
Labels	Bug
Assignee	@beccadax
Priority	Medium

md5: c8192564d3ce9290205bc02403bb0bdf

Issue Description:

Previously raised in: https://forums.swift.org/t/swifinterface-undeclared-generic-types/37706

Good afternoon.

I'm trying to extract some internal frameworks from our project and move them to their own repository. I've started with a framework which is a dependency of both the app and most of the other internal frameworks in the app (yes exactly, the "utils" library 🙂).

The utils library also have other third party dependencies, which are resolved using Cocoapods. The library is compiled into an XCFramework correctly. This XCFramework is then linked back to the main app and to every internal framework depending on it. "Utils" dependencies are added to the main app and the internal frameworks using Cocoapods as well.

When I try to compile the app, the compilation of the swiftinterface fails, as it can't infer the types being used in a generic class's extension. This generic class is Result, which is part of Swift. The interface file contains import Swift so I have the impression some of the other imports may be failing and causing this, but my knowledge of how the compiler works is pretty limited.

I understand this is a pretty specific case of interface, as it contains imports of third parties, but I'd assume this is a pretty standard setup in big projects. I also understand the setup might be wrong, in which case I'd need to understand where the error is.

I've attached a test project with an app/ and a library/ folders containing a __ minimal version of this setup. Run bundler install and bundle exec pod install in both projects beforehand. The library one contains the standard script to create xcframeworks, and the one included in the app has been generated in this way.

Please, do let me know if I can provide more info and help. I hope it's a setup error in the end. Thanks!

[typesanitizer]

I don't see any setup error. Here are the steps I ran:

1. Ran bundler install in library/.
2. Ran bundler exec pod install in library/.
3. Ran bundler install in app/.
4. Ran bundler exec pod install in app/.

I do see a warning like

[!] The Podfile contains framework or static library targets (MyLibrary), for which the Podfile does not contain host targets (targets which embed the framework).
If this project is for doing framework development, you can ignore this message. Otherwise, add a target to the Podfile that embeds these frameworks to make this message go away (e.g. a test target).

after the bundler exec pod install steps but that's not what you're talking about, right?

[swift-ci]

Comment by Marcos Hernandez (JIRA)

The setup is correct. But when I try to compile the app, it fails, as the compiler can't infer the generic types defined within the .swiftinterface.

[typesanitizer]

Gotcha'. When I compile the app, I end up seeing errors like

Cannot find type 'Success' in scope
Cannot find type 'Failure' in scope 

and so on in extension Result generated in the swiftinterface for MyLibrary. It seems a bit strange that we emit the standard library's extension in the library's swiftinterface. Potentially relevant: one of the dependencies PromiseKit also has its own Result type.

[typesanitizer]

@swift-ci create

[swift-ci]

Comment by Marcos Hernandez (JIRA)

Indeed, it looks like PromiseKit's Result might be impacting somehow. I expected these types to be somehow "namespaced" so to say, to avoid collisions. I'm not sure how much context the compiler has when it's evaluating a library's swiftinterface.

Thanks for moving this forward theindigamer (JIRA User) !

[beccadax]

When we print the module interface for MyLibrary, we print extension Result. I'm pretty sure this is wrong—we ought to fully qualify it as extension Swift.Result.

[beccadax]

printExtendedTypeName() does this on purpose, but as far as I can tell, this was done back when this code was only used for user-facing features, like documentation and Xcode generated interfaces. It may not be desired behavior for module interfaces.

On the other hand, at least one test (SourceKit/CodeComplete/complete_swiftinterface.swift) starts failing when I fix it because of the sort of module name shadowing issue that forces use of -module-interface-preserve-types-as-written, so there's some potential for this change to break modules that are currently (somewhat accidentally) working fine. We'll have to evaluate the source compatibility impact.

[beccadax]

#32780