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

[SR-805] Generated header is missing imports in C++ mode #43417

Open
jpsim opened this issue Feb 24, 2016 · 6 comments
Open

[SR-805] Generated header is missing imports in C++ mode #43417

jpsim opened this issue Feb 24, 2016 · 6 comments

Comments

@jpsim
Copy link
Contributor

@jpsim jpsim commented Feb 24, 2016

Previous ID SR-805
Radar rdar://problem/23891356
Original Reporter @jpsim
Type Bug

Attachment: Download

Environment

Xcode 7.2.1

Additional Detail from JIRA
Votes 2
Component/s Compiler
Labels Bug, PrintAsObjC
Assignee None
Priority Medium

md5: 457f19e0f6ae0577426276124a6b4a72

Issue Description:

The generated '{modulename}-Swift.h' file fails to compile when 3 or more modules are involved with the following configuration:

1. FrameworkA has an Objective-C class 'ClassA'.
2. FrameworkB has a Swift class 'ClassB' subclassing 'ClassA' with an '@objc' annotation of a different name ('FrameworkBClassB').
3. FrameworkC has a Swift subclass 'ClassC' subclassing 'ClassB' and an Objective-C++ file importing the Xcode-generated (via PrintAsObjC) '{modulename}-Swift.h'.

FrameworkC fails to compile in this case. If the '.mm' file is renamed to '.m', FrameworkC compiles. If the '-Swift.h' file isn't imported, FrameworkC compiles.

You'd be forgiven to assume that this is an arcane configuration that would never happen in practice, but you'd be wrong (cue nervous laughter). See realm/realm-swift#3073

I've attached a sample Xcode project, to reproduce this issue, just build the FrameworkC target using Xcode 7.2.1.

@belkadan
Copy link
Contributor

@belkadan belkadan commented Jun 14, 2017

This happens because the generated header uses @import (appropriately guarded) rather than #import. Copying some notes out of Radar:

  • For framework modules with umbrella headers, we can just include the umbrella header.

  • For header modules with umbrella headers, we can include the umbrella header by absolute (sysroot-relative) path.

  • For modules without umbrella headers, we can include every header in the appropriate submodule manually.

That last may not actually work because some submodule headers depend on other headers having been included.

(I'm not actually sure the "sysroot-relative" thing works, but even just handling the simple "frameworks with umbrella header" case would be a good improvement that probably follows the 80/20 rule.)

@belkadan
Copy link
Contributor

@belkadan belkadan commented Oct 30, 2019

I got a start on this (imports.patch), but ran into difficulty figuring out how to actually spell the headers. The attached patch is doing some terrible parent directory sniffing to see if we're in a framework or something that looks like a search path, but I don't know if that's really the way to go.

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Jun 8, 2020

Comment by Matthew Benedict (JIRA)

I have this issue in another configuration. I have a drawer controller with open access level declared in a package, which I have imported and inherited from in a Swift file. Upon compiling, the same error occurs: "Cannot find interface declaration for 'ZKDrawerController', superclass of 'ReviewContainerViewController'"

@belkadan, or anyone else, should I post this as a separate issue, or is this the same? Thank you!

@belkadan
Copy link
Contributor

@belkadan belkadan commented Jun 8, 2020

Where is that error emitted? Is it from an Objective-C++ source file? If not, it's probably a different issue.

@swift-ci
Copy link
Collaborator

@swift-ci swift-ci commented Jun 16, 2020

Comment by Matthew Benedict (JIRA)

@belkadan, I reported it at https://bugs.swift.org/browse/SR-12954 as a separate issue based on your comment, before realising that they are in fact one and the same issue. Could you please mark that as a duplicate of this? Hopefully the additional information helps you resolve this!

@belkadan
Copy link
Contributor

@belkadan belkadan commented Jun 16, 2020

You should be able to do it too: go to your new bug and choose Resolve Issue, then select "Duplicate" and add this SR as the issue it duplicates.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants