Swift extraction reports ambiguous NSAccessibilityElement for valid PDFKit source

CodeQL 2.27.2 reports an ambiguous NSAccessibilityElement while extracting a small public Swift file that Apple Swift compiles and runs successfully. An explicit import class AppKit.NSAccessibilityElement leaves the same error. This comparison disproves that import as a remedy on the tested toolchain.

The baseline is the unchanged MIT-licensed Sources/ArgmaxCore/FileUtilities.swift from Argmax OSS Swift (formerly WhisperKit), revision 26577ce3017aae8c9edfd9a0dd17851bd248c731. Its SHA256 is 0578c91c01ab86695a6e56bb898480171c4d879b6eaad8a494fd321b75e98c4a. The treatment adds only this import inside the existing PDFKit guard:

#if os(macOS)
import class AppKit.NSAccessibilityElement
#endif

The tested environment was:

• Xcode 26.6, build 17F113; macOS SDK 26.5.
• Apple Swift 6.3.3: swiftlang-6.3.3.1.3 clang-2100.1.1.101; driver 1.148.6.
• Explicit compile target arm64-apple-macos13.0, Swift 5 language mode, cross-import overlays enabled. swiftc --version reports the compiler's default target as arm64-apple-macosx26.0.
• CodeQL 2.27.2, official Swift macOS bundle, codeql-bundle-swift-osx64.tar.zst.
• Bundle SHA256: 25a08dfd23997ccf6374b5a70d9aa27a510e027f1b5aed60e1a653f8a3596375.
• swift/tools/osx64/extractor.real SHA256: 680adbee37bdbfc5fe0a4b6d63c45bdae23fcf3bb2210530a7b751b58f319530.

The attachment contains both source variants, the original license, a behavior harness, invented text/PDF fixtures and reproduce.sh. Run it with the verified CodeQL executable and a new output directory:

bash reproduce.sh /absolute/path/to/codeql/codeql /absolute/path/to/new-output

The script preserves the tested compiler arguments, creates a fresh module cache and separate CodeQL database for each variant, then runs codeql/swift-queries:codeql-suites/swift-code-scanning.qls. The attached shell wrapper was checked with Bash syntax validation and ShellCheck. The recorded hosted execution used the equivalent commands in a Python harness; the shell wrapper itself has not been executed end to end.

Expected: both valid sources compile normally and extract without a compiler-error notification.

Actual: ordinary compilation, database creation and analysis all exit zero for both variants. Each SARIF nevertheless contains one swift/diagnostics/extraction-errors notification:

Compiler error in  with error message reference to 'NSAccessibilityElement' is ambiguous

Each extractor log also contains this error:

ERRO [extractor/compiler] <invalid loc>:0:0 reference to 'NSAccessibilityElement' is ambiguous (SwiftDiagnosticsConsumer.cpp:62)

The six cases cover UTF-8 text, Latin-1 text, empty and missing files, invalid PDF input, and text/page order in a two-page PDF. Both behavior outputs have SHA256 46668bfa093cbbbb35dd864350e992e0f8bcba65985833195bf455fac47d4735.

The explicit class import preserves the tested behavior but does not resolve the extractor error. Please identify an extractor correction or a supported remedy that clears this reproducible error while preserving PDFKit behavior.

upstream-public-approval.zip

Attachment SHA256: 1e00b9184f9002b0beb26f7488a8922ced3a815aa08a66127681b6178efcefda (6,846 bytes).