fix(cl): Async++ conversion operator reaches unknown cursor kind 26
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
The panic comes from the loadDecl switch in cl/preload.go, which has no case for Cursor_ConversionFunction, though the class-local newClassCtx path already handles it; compare the two to see how that cursor kind is treated. Reproduce by generating bindings for the Async++ headers with llcppg as described in the issue, or start from explicit operator bool() in ref_count.h:146. Done when that header no longer panics with kind 26 and the conversion operator is handled consistently with the existing path.
索引モデルが issue の本文から書いたものです。
説明
Observed failure
The recursive installed-header generation for Async++ reaches explicit operator bool() const in async++/ref_count.h:146 and panics in loadDecl with cursor kind 26.
panic: .../include/async++/ref_count.h:146:2: loadDecl: unknown kind - 26
github.com/goplus/llcppg/cl.loadDecl
cl/preload.go:152
Confirmed Linux arm64 CI job. Formula testing and both compiler/tool builds succeeded; Test llcppg generation is the failing step. Other matrix jobs were still pending when this report was prepared, so this is not a claim that every platform has reproduced the failure.
Versions and reproduction input
- llcppg:
8fc0f987e41ffe4b4f608e9541422b460ea89fea. - LLGo:
afe9a5407260348b18c7104e98d76cb5cdf48b29; LLVM 21, Linux arm64. - Actual installed source: Amanieu/asyncplusplus
v1.2, commit4159da79e20ad6d0eb1f13baa0f10e989edd9fba, ref_count.h. - Failed configuration is from index PR #7, head
49abce7:
{
"Name": "async",
"Language": "c++",
"Dir": "./include/...",
"LLGoPackage": "link: $(pkg-config --libs async++)",
"NSPrefix": ["async::"]
}
Stage the installed headers under source/include, initialize the source Go module as in the linked workflow, and run llcppg -v ./generated ./source. There is no Files allowlist or ignored API in this configuration.
Expected behavior and source evidence
A valid conversion operator should not fall into an unknown-cursor panic. The current-main loadDecl switch handles CXX methods, constructors, and destructors, but not Cursor_ConversionFunction. The same file's class-local newClassCtx path does handle Cursor_ConversionFunction, so the existing handling does not cover the path reached by this input.
Latest main (aab6dbf0baedc47b42f9576a65dd79ce6715e31a) was inspected only, not executed. The job also logs missing-package warnings for some GCC 14 C++ headers; their causal relationship to this panic has not been established and is not asserted here.
- 主要言語
- Go
- スター
- 39
- フォーク
- 13
- 平均マージ
- 1時間 28分
- マージ済み PR（30日）
- 256
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
goplus/llcppg のほかの issue
-
bug
難易度 5/5 1週間以上 初心者へのやさしさ 28/100
メンテナーはふだん 1 日以内に返信
-
bug
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
メンテナーはふだん 1 日以内に返信
-
feature proposal
難易度 5/5 1週間以上 初心者へのやさしさ 18/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
Architecture-Design feature to be confirm
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
QuantumNous/new-api#7839 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
puppe1990/amarra-cais#355 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
Gentleman-Programming/engram#1899 ·
メンテナーはふだん 1 日以内に返信
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
メンテナーはふだん 1 日以内に返信