swift_import not linked with ios_unit_test about rules_swift

[allevato]

I also noticed that swift_import takes multiple archives, and multiple swiftmodules, this seems to conflict with new_objc_provider which expects only 1 of each of these. Would it be reasonable to either remove the array support from swift_import and require multiple swift_imports per module, or possibly assume the indexes of the libraries line up with their swiftmodules in the definition?

I think we want to retain the ability to list multiple modules and libraries in the rule; in the future I'd like for swift_import to have smarter handling of framework-based modules (where you have the Modules subdirectory with a file for each architecture), and it's a much better user experience for the BUILD author to just glob those and let the compiler sort it out than to select the right one based on target architecture.

Likewise, requiring indices to line up is fragile, so we should avoid that.

I'll have some feedback on your PR soon—the past couple weeks have been hectic and I'm trying to get some other changes pushed out that might affect your work.

[allevato]

I think I see what's happening here.

ios_unit_test uses apple_binary underneath to link the binary. Unlike swift_binary, apple_binary is a native rule so it doesn't know anything about SwiftInfo provider; it can only get the libraries that need to be linked from the Objc provider. We make this work for swift_library by also creating and propagating an Objc provider with the library in it: https://github.com/bazelbuild/rules_swift/blob/master/swift/internal/api.bzl#L626

So fixing this should just be a matter of having swift_import also propagate an Objc provider.

[keith]

Thanks for the context, I've looked into a fix a bit more for this, it looks like there might be another issue related to this ObjC vs Swift rule. It seems like the SwiftToolchainInfo created here may also not be propagated, leading the the linker flags to the Swift libraries not being included in the final link. Would this make sense?

I also noticed that swift_import takes multiple archives, and multiple swiftmodules, this seems to conflict with new_objc_provider which expects only 1 of each of these. Would it be reasonable to either remove the array support from swift_import and require multiple swift_imports per module, or possibly assume the indexes of the libraries line up with their swiftmodules in the definition?

[keith]

I've submitted an solution to this problem for discussion #38