Repository navigation
Swift extractor: lazy declaration TRAP file name exceeds 255 bytes for C++ template specializations #22843
Description
Description of the issue
The Swift extractor fails to write the TRAP file for a lazily extracted declaration when the declaration's name is a long C++ template specialization. The file name exceeds the 255-byte limit on macOS, so opening it fails with ENAMETOOLONG and the extractor reports an internal error.
Assertion failed: `(*__error()) == 17`. Unable to open /Users/runner/work/_temp/codeql_databases/swift/trap/swift/lazy_decls/__ObjC/Struct_optional<std.__1.variant<margelo.nitro.NullType, std.__1.vector<std.__1.basic_string<CChar, std.__1.char_traits<CChar>, std.__1.allocator<CChar>>, std.__1.allocator<std.__1.basic_string<CChar, std.__1.char_traits<CChar>, std.__1.allocator<CChar>>>>>>_496c496d2da3e26471a167a87ade75de.trap for writing (system:63)
Some or all of the Swift analysis may have failed.
The type is std::optional<std::variant<NullType, std::vector<std::string>>>, generated by Nitro Modules and imported through Swift/C++ interop. The job itself succeeds and the SARIF uploads; only this declaration is missing from the database.
Cause
mangledDeclName in swift/extractor/SwiftExtractor.cpp already hashes the mangled name because it "can be too long for file names", but it still appends the full userFacingName() before the hash. For a C++ template specialization that readable part alone can be longer than 255 bytes. getRelativeTrapPath in swift/extractor/infra/TargetDomains.cpp then uses the result as the file name unchanged.
A possible fix is to cap the readable part (for example, to a few dozen bytes) before appending the hash, so the hash keeps names unique.
Environment
- CodeQL CLI 2.27.2,
github/codeql-actionv4 (24c54180a607b1449ed407dd24f251e4e9147c8d) - GitHub-hosted macOS runner,
build-mode: manual, Swift analysis of a React Native library with Nitro Modules - Public reproduction: job log from hyodotdev/openiap (
libraries/react-native-iap). It reproduces on every run of that job.
Activity
jketema commentedon Oct 20, 2026
Hi @hyochan
Thanks for the report. We'll have a look at fixing this.
jketema commentedon Oct 21, 2026
We've put a mitigation in place (see #22851). This skips extraction in the case the file name gets too long. Consequently there will be some small gaps in the created database, but this is unlikely these will affect analysis much.
We're currently working on a replacement solution for Swift, so we prefer it mitigate here instead of fully fixing.
The fix should be part of CodeQL 2.27.4.
I'll leave this open, as this is technically still an unresolved bug.