Skip to content

[ClangImporter] Handle DeclContexts that may not originate from Clang modules#88115

Draft
oskarwirga wants to merge 1 commit intoswiftlang:mainfrom
oskarwirga:arm64e/clangimporter-fix
Draft

[ClangImporter] Handle DeclContexts that may not originate from Clang modules#88115
oskarwirga wants to merge 1 commit intoswiftlang:mainfrom
oskarwirga:arm64e/clangimporter-fix

Conversation

@oskarwirga
Copy link
Copy Markdown

Summary

  • Change cast to dyn_cast in three ClangImporter locations where the DeclContext may originate from a Swift module re-imported via a -Swift.h bridging header.
  • The hard cast asserts when processing Swift-originated methods that come back through the Clang importer during bridging header processing. This occurs more frequently under arm64e due to additional ObjC metadata processing, but the fix is not arm64e-specific.
  • The fix follows standard LLVM/Swift patterns for handling polymorphic DeclContexts. dyn_cast returns null and the existing fallback paths handle it.

Test plan

  • Existing ClangImporter tests continue to pass.
  • Verified against projects that use -Swift.h bridging headers with ObjC interop.

@swift-ci Please smoke test

… modules

Change cast<ClangModuleUnit> to dyn_cast<ClangModuleUnit> in several
places where the DeclContext may not originate from a Clang module.
This occurs when Swift-originated methods are re-imported via a
generated -Swift.h bridging header. The hard cast crashes when
processing these re-imported declarations, which happens more
frequently under arm64e due to additional ObjC metadata processing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant