Introduce "-internal" variant of bridging header import flags #84410

DougGregor · 2025-09-19T22:21:57Z

The flags "-import-bridging-header" and "-import-pch" import a bridging header, treating the contents as a public import. Introduce "internal-" variants of both flags that provide the same semantics, but treat the imported contents as if they came in through an @_implementationOnly internal import instead. This helps us keep the the bridging header as an implementation detail.

This is only plausibly safe with library evolution enabled, so warn about that.

Tracked by rdar://74011750.

tshortli · 2025-09-19T22:55:29Z

include/swift/AST/DiagnosticsSema.def

     "'%select{private|fileprivate|internal|package|%ERROR|%ERROR}1' "
-     "from %2",
-     (const Decl *, AccessLevel, const ModuleDecl*))
+     "from %select{%2|bridging header}3",


I feel like there may be more resilience diagnostics that will need to be updated, but it seems like this is a good start

Perhaps! They'll come out as the weird __ObjC module if we don't customize them.

A new kind of DisallowedOriginKind may do the trick here.

Ah, that could help here, yes.

I did this in b7a8349

xymus · 2025-09-19T23:29:23Z

lib/Sema/ImportResolution.cpp

        ImportedModule(headerModule), SourceLoc(), ImportFlags::Exported);
+    if (ctx.ClangImporterOpts.BridgingHeaderIsInternal) {
+      import.accessLevel = AccessLevel::Internal;
+      import.options |= ImportFlags::ImplementationOnly;


The mix of @_implementationOnly internal import isn't exactly an expected configuration at the moment. I'm worried that checks for both could overlap and duplicate the exportability diagnostics. We could use only internal import for library-evolution enabled modules if it's an issue.

Do we still see the warnings on implementation-only use from non-library-evolution modules for an implicit import like this?

Hmm, looks like we don't need both internal and @_implementationOnly to get the diagnostics I've been checking. I'll remove it for now.

…ad of `-import-objc-header` This command-line option hasn't been Objective-C specific ever, really. Make the language-independent spelling the primary one to make that more obvious.

The flags "-import-bridging-header" and "-import-pch" import a bridging header, treating the contents as a public import. Introduce "internal-" variants of both flags that provide the same semantics, but are intended to treat the imported contents as if they came in through an internal import. This is just plumbing of the options for the moment.

When using an internal import for a bridging header, semantically treat the contents of the bridging header, and anything that it imports, as if they were imported internally. This is the actual semantic behavior we wanted from internally-imported bridging headers. This is the main semantic checking bit for rdar://74011750.

C++ namespaces always get imported into the bridging header's module for Reasons. Exempt them from internal-import checking, since we get checking for the namespace members that are actually used.

…tion It's very, very easy to make a mistake that will cause broken serialized modules. Until that's no longer true, at least tell folks that they are heading into uncharted waters, as we do with `@_implementationOnly` imports.

Internally-imported bridging headers must not leak outside of the Swift module. Don't serialize their contents, and make sure we can still import the module even if the bridging header has been removed.

…ernal bridging headers

DougGregor · 2025-09-20T00:13:17Z

@swift-ci please smoke test

DougGregor · 2025-09-20T00:15:51Z

@swift-ci please smoke test macOS

DougGregor · 2025-09-20T00:43:27Z

@swift-ci clean smoke test macOS

DougGregor · 2025-09-20T03:10:25Z

@swift-ci clean smoke test macOS

DougGregor · 2025-09-20T03:10:33Z

@swift-ci please smoke test

DougGregor · 2025-09-20T04:52:06Z

@swift-ci please smoke test Windows

…ing headers

DougGregor · 2025-09-22T18:12:07Z

@swift-ci please smoke test

ian-twilightcoder · 2025-09-22T22:21:00Z

Can we add a feature flag for this in lib/Option/features.json for swift-build to pick up? (There's still a few cases where they don't use swift-driver)

DougGregor · 2025-09-22T23:16:51Z

swiftlang/swift-driver#1993

@swift-ci please smoke test Windows

DougGregor · 2025-09-22T23:36:54Z

@swift-ci please smoke test

ian-twilightcoder

This is awesome, thank you so much for doing this!

include/swift/Frontend/FrontendOptions.h

include/swift/Option/Options.td

lib/ClangImporter/ClangImporter.cpp

lib/Sema/TypeCheckAccess.cpp

lib/Sema/TypeCheckAccess.h

…tual interface

DougGregor · 2025-09-23T00:11:28Z

@swift-ci please smoke test

ian-twilightcoder · 2025-09-23T00:11:36Z

Instead of making a separate -internal-import-bridging-header flag, should we have -bridging-header-is-internal? Because the next thing people will want is -bridging-header-is-system to make the NSUIntegers in their project internal headers consistently translate to Int.

DougGregor · 2025-09-23T15:07:50Z

Instead of making a separate -internal-import-bridging-header flag, should we have -bridging-header-is-internal?

I'd rather not, because having -internal-import-bridging-header be its own separate thing makes it easier for us to deprecate and move away from the non-internal version.

DougGregor requested review from Xazax-hun, artemcm, beccadax, egorzhdan, fahadnayyar, hborla, ian-twilightcoder, j-hui, slavapestov, susmonteiro, tshortli, xedin and zoecarver as code owners September 19, 2025 22:21

tshortli reviewed Sep 19, 2025

View reviewed changes

xymus reviewed Sep 19, 2025

View reviewed changes

xymus approved these changes Sep 19, 2025

View reviewed changes

DougGregor added 7 commits September 19, 2025 16:49

[Options] Make -import-bridging-header the canonical spelling inste…

ffa6d65

…ad of `-import-objc-header` This command-line option hasn't been Objective-C specific ever, really. Make the language-independent spelling the primary one to make that more obvious.

Exempt C++ namespaces from internal-import checking

903937a

C++ namespaces always get imported into the bridging header's module for Reasons. Exempt them from internal-import checking, since we get checking for the namespace members that are actually used.

[Serialization] Don't serialize an internally-imported bridging header

30bdb6b

Internally-imported bridging headers must not leak outside of the Swift module. Don't serialize their contents, and make sure we can still import the module even if the bridging header has been removed.

Improve some diagnostic with @_implementationOnly violations from int…

7bc02d6

…ernal bridging headers

DougGregor force-pushed the internal-import-bridging-header branch from 84a2d2c to 7bc02d6 Compare September 19, 2025 23:50

Don't mix internal and @_implementationOnly

52ebe09

Add #include guards around bridging header

d04e6dd

Expand DisallowedOriginKind with an explicit entry for internal bridg…

b7a8349

…ing headers

DougGregor mentioned this pull request Sep 22, 2025

Handle "-internal-import-bridging-header" swiftlang/swift-driver#1993

Merged

ian-twilightcoder approved these changes Sep 22, 2025

View reviewed changes

DougGregor added 5 commits September 22, 2025 17:09

Add -internal-import-bridging-header as a supported feature

085f3b4

Ensure that -internal-import-bridging-header doesn't show up in a tex…

a1bc577

…tual interface

Temporarily disable on Windows

67a9fe0

Remove unnecessary addition of @_implementationOnly

511ce96

Clean up help text for new option

87cbe5d

DougGregor force-pushed the internal-import-bridging-header branch from 4ebc6dd to 87cbe5d Compare September 23, 2025 00:11

DougGregor merged commit 90a5a0f into swiftlang:main Sep 23, 2025
3 checks passed

DougGregor deleted the internal-import-bridging-header branch September 23, 2025 06:09

Introduce "-internal" variant of bridging header import flags #84410

Introduce "-internal" variant of bridging header import flags #84410

Uh oh!

Conversation

DougGregor commented Sep 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tshortli Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

DougGregor Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

xymus Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

DougGregor Sep 20, 2025

Choose a reason for hiding this comment

Uh oh!

DougGregor Sep 22, 2025

Choose a reason for hiding this comment

Uh oh!

xymus Sep 19, 2025

Choose a reason for hiding this comment

Uh oh!

DougGregor Sep 20, 2025

Choose a reason for hiding this comment

Uh oh!

DougGregor commented Sep 20, 2025

Uh oh!

DougGregor commented Sep 20, 2025

Uh oh!

DougGregor commented Sep 20, 2025

Uh oh!

DougGregor commented Sep 20, 2025

Uh oh!

DougGregor commented Sep 20, 2025

Uh oh!

DougGregor commented Sep 20, 2025

Uh oh!

DougGregor commented Sep 22, 2025

Uh oh!

ian-twilightcoder commented Sep 22, 2025

Uh oh!

DougGregor commented Sep 22, 2025

Uh oh!

DougGregor commented Sep 22, 2025

Uh oh!

ian-twilightcoder left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

DougGregor commented Sep 23, 2025

Uh oh!

ian-twilightcoder commented Sep 23, 2025

Uh oh!

Uh oh!

DougGregor commented Sep 23, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

DougGregor commented Sep 19, 2025 •

edited

Loading