[SR-3801] Importing an app target with a bridging header in tests results in a deprecation warning for implicit imports of bridging headers

[swift-ci]

Previous ID	SR-3801
Radar	rdar://problem/30202509
Original Reporter	ssheldon (JIRA User)
Type	Bug

Attachment: Download

Environment

macOS 10.12.3, Xcode 8.3 beta

Additional Detail from JIRA

Votes	0
Component/s
Labels	Bug, 3.1Regression
Assignee	graydon (JIRA)
Priority	Medium

md5: 138a2e21b3d20afe9f261addc4340743

Issue Description:

Steps to repro:

1. write an app target with a bridging header (let's say our app is called Baz)

2. write a Swift test case that imports that app, either via import Baz or @testable import Baz

3. compile the test target and observe a warning

The warning given is:

Implicit import of bridging header 'Baz-Bridging-Header.h' via module 'Baz' is deprecated and will be removed in a later version of Swift

If the warning is legitimate, it's unclear how it should be fixed. The only fixes I've found are removing the import (but then you can't test your code from Swift) or deleting the app's bridging header (but then you can't use your app's ObjC from its Swift).

[swift-ci]

Comment by Steven Sheldon (JIRA)

This warning was introduced in 08af6f0, cc graydon (JIRA User)

Is there a way that tests should be configured for mixed ObjC/Swift targets to avoid this warning? When creating a brand new Swift app with tests in Xcode, as soon as I add an ObjC file and a bridging header this warning starts to appear.

[swift-ci]

Comment by Graydon Hoare (JIRA)

Yeah, it was introduced a little too aggressively in that patch which made it into beta 1, sorry! We're aware and have dialed it down a ways (see: #7045 ) but it's going to take a little while to percolate through to a release build. It's in nightly snapshots already if you want to install one of those.

If you don't want to wait, the workarounds are:

1. explicitly import the App bridging header into your unit tests (via a build setting) or

2. chain the import by adding #import "App-Bridging-Header.h" to any existing unit test bridging header you have

[swift-ci]

Comment by Steven Sheldon (JIRA)

Thanks and no problem, I wanted to make sure it was reported before the full Xcode 8.3 release but you're way ahead of me 🙂

Feel free to close this out if it's been fixed by that pull request, I can try corroborating with a nightly snapshot sometime.

[swift-ci]

Comment by Steven Sheldon (JIRA)

Okay I've tried this out on Xcode 8.3 beta 3 using the Swift 3.1 2017-03-05 toolchain, and the original case I reported doesn't warn anymore. However if you add a bridging header to the tests (even an empty one) the warning starts appearing again. I've attached a second repro case.

Is that expected? i.e. are we required to chain the import like described in workaround #2 above? (A tweet from Jordan seems to imply that this might be expected)

[swift-ci]

Comment by Graydon Hoare (JIRA)

Yes it's expected in that context (that's the context the followup fix narrowed it to). Chaining the bridging headers together is the intended fix. Long-term, we'd like to phase out support for the implicit imports altogether, which means that chaining or explicit imports will be the only mechanism that remains working.

[swift-ci]

Comment by Steven Sheldon (JIRA)

Got it. If there's any way to change this diagnostic so that it suggests adding the import to the bridging header, that might be helpful. Otherwise I think this is fine to close out.

Thanks for your help Graydon!

[swift-ci]

Comment by Erik Aigner (JIRA)

Is this ever going to be fixed? Still can't import a single mixed framework without generating tons of warnings. The workarounds listed here are not valid solutions, the bridging header should not be exposed to any importing project at all.