-
Notifications
You must be signed in to change notification settings - Fork 0
自己完結していないライブラリファイルを自動検出して警告する #94
Copy link
Copy link
Open
Labels
Kind/EnhancementImprove existing functionalityImprove existing functionalityModule: BundleThe tree-shaking pipelineThe tree-shaking pipelineModule: LibraryThe library registration domainThe library registration domainPriority/HighThe priority is highThe priority is highSilent FailureBug that exits 0 while producing incorrect outputBug that exits 0 while producing incorrect output
Description
Metadata
Metadata
Assignees
Labels
Kind/EnhancementImprove existing functionalityImprove existing functionalityModule: BundleThe tree-shaking pipelineThe tree-shaking pipelineModule: LibraryThe library registration domainThe library registration domainPriority/HighThe priority is highThe priority is highSilent FailureBug that exits 0 while producing incorrect outputBug that exits 0 while producing incorrect output
#20で文書化した「各ファイルの自己完結性」の違反は、現状ユーザーが自分で気をつけるしかない。特に namespace で他ファイルの#includeをラップする構成は、修飾なしで使うと黙って意味が変わったままコンパイルが通り得る (Silent Failure)。自動で検出して警告できれば、文書を読んでいないユーザーも守れる。検出方式は 2 案あり、どちらにするか (または併用するか) は要検討。
案 A: 登録時 (
library add/update) に tree-sitter で検出するpreproc_includeノードの祖先に C++ のスコープ (namespace_definition・declaration_list・compound_statement・クラス本体) がいたら警告する。#ifdef _MSC_VER→#include <intrin.h>のようなプリプロセッサ条件の内側は正当 (AC Library が実際にやっている) なので、preproc_if/preproc_ifdef系の祖先は許す区別が必要で、実験ではこの区別で正しく分離できた。#includeを書いたファイル) だけ。相方の断片ファイル単体や、#includeを使わない関数分割 (int f() {/}の 2 ファイル) は検出できない。なお tree-sitter の
has_error()で構文の非完結を直接検出する案は不適と判明している。波括弧なしの文レベルマクロ (rep(i, n) s += i;) や属性マクロ付きの関数定義 (ATTR_HOT int f()) という競プロライブラリの日常的な書き方が ERROR になり、偽陽性が多すぎる。「正当な操作で必ず消える警告だけを出す」方針 (architecture.md) に反する。案 B: バンドル時にプリプロセス結果のファイル境界で検出する
プリプロセス出力を字句解析して波括弧の深さを追跡し、linemarker によるファイルの切り替わりが深さ 0 以外の位置に来ていたら警告する。
#ifdef分岐だけを見るので、プリプロセッサ起因の偽陽性もない。補足
関連: #20 (条件の文書化)、#93 (文書の PR)
🤖 Generated with Claude Code