Swift extraction reports ambiguous NSAccessibilityElement for valid PDFKit source
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 15/100
调研方向
Start with the attached reproduce.sh and run it against the baseline and treatment Swift sources on macOS with the CodeQL bundle. Then read the extractor log entry citing SwiftDiagnosticsConsumer.cpp:62 to see how the 'ambiguous' diagnostic is produced. Done means both variants extract with no swift/diagnostics/extraction-errors notification while the PDFKit behavior cases still pass.
由索引模型根据 Issue 内容生成。
描述
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 --versionreports the compiler's default target asarm64-apple-macosx26.0. - CodeQL 2.27.2, official Swift macOS bundle,
codeql-bundle-swift-osx64.tar.zst. - Bundle SHA256:
25a08dfd23997ccf6374b5a70d9aa27a510e027f1b5aed60e1a653f8a3596375. swift/tools/osx64/extractor.realSHA256: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)
| Result | Baseline | Explicit class import |
|---|---|---|
| Apple file/PDF behavior cases passed | 6 | 6 |
| Required source included | 1/1 | 1/1 |
| SARIF extraction errors | 1 | 1 |
| Unresolved AST nodes | 0 | 0 |
| Extracted AST nodes | 532386 | 525362 |
| Successfully extracted lines | 35 | 36 |
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.
Attachment SHA256: 1e00b9184f9002b0beb26f7488a8922ced3a815aa08a66127681b6178efcefda (6,846 bytes).
- 主要语言
- CodeQL
- 星标
- 10.2k
- 派生
- 2.1k
- 平均合并
- 2 天 11 小时
- 30 天内合并 PR
- 155
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
github/codeql 的其他 Issue
-
false-positive javascript
难度 2/5 1-3 小时 新手友好度 84/100
维护者通常 1 天内回复
-
Add AlertSuppression.ql for Rust (inline // codeql[...] suppression)可能已有人在做 @cnuss 于 192 天前认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
false-positive
难度 2/5 1-3 小时 新手友好度 70/100
github/codeql#21076 · 3 条评论 · 3 个 reaction ·
维护者通常 1 天内回复
-
Rust: extraction succeeds with missing proc-macro output when the project's `rust-version` exceeds the forced toolchain可能已有人在做 @paldepind 于 2 天前认领。 未关闭
github/codeql#22793 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Actions: `uses: $/…` self-repository references are not resolved to local reusable workflows or composite actions (false positives and downgraded severity)可能已有人在做 @WilliamBerryiii 于 2 天前认领。 未关闭
难度 3/5 1-2 天 新手友好度 62/100
github/codeql#22755 · 1 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
相似的 Issue
-
flang:semantics
难度 2/5 1-3 小时 新手友好度 73/100
llvm/llvm-project#231051 ·
维护者通常 1 天内回复
-
bug derived types format I/O medium priority semantics
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
lexer: a lone `"` at the end of a file panics instead of reporting an error可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
bytecodealliance/wasm-tools#2768 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
antlr/grammars-v4#5035 ·
维护者通常 5 天内回复