Hackの深淵：カスタムAttributeを用いた静的解析の「コンパイル時強制」
HHVMのコードベースに深く潜り込み、型チェッカー（`hh_client`）の挙動を制御することは、単なるコード規約の強制ではない。それは、ランタイムの安全性を担保する「要塞」を設計することに等しい。
多くの開発者は、Hackの`<<__Attribute>>`を単なるメタデータの付与手段と誤解している。だが、我々アーキテクトにとって、これは型チェッカーの解析フェーズに独自の論理を注入するための「フック」である。
今日は、標準の型推論では捉えきれない、プロジェクト固有の「ドメイン制約」を、コンパイル時に静的に封じ込める手法を伝授する。
—
1. 型チェッカーの限界と拡張の哲学
Hackの厳格モード（`<<__Strict>>`）は強力だが、ビジネスロジックに深く根ざした制約——例えば「特定の機密プロパティを持つクラスは、必ず特定のインターフェースを実装しなければならない」といったルール——は、標準の型システムでは記述できない。
これを解決するために、HHVMの`Hack`実装そのものをハックする必要はない。`Custom Attribute`と`hh_server`の拡張機能（または静的解析用のアドオン）を組み合わせ、コンパイルパイプラインにチェックを介入させるのだ。
2. カスタムAttributeの設計：メタデータの物理構造
まずは、解析器が識別可能な属性を定義する。ここでは、特定のメソッドが「外部からのデータ投入を禁止する（ReadOnly）」という独自のルールを強制する例を考える。
namespace App\Attributes;
// 属性の適用範囲をメソッドに限定（Targetは設計の要）
<<__Attribute(__Method)>>
final class StrictDataIntegrity implements \HH\ClassAttribute {
public function __construct(
private bool $enforceImmutable = true,
) {}
}
この属性自体はただのマーカーに過ぎない。真の価値は、この属性を付与したメソッドを走査する静的解析スクリプト（または自作のチェッカープラグイン）にある。
3. 型チェッカーの解析フェーズへの介入
HHVMの内部構造において、型チェッカーはAST（抽象構文木）を走査し、型推論グラフを構築する。このグラフに対して、我々は独自のバリデーターを走らせる。
以下は、`hh_parse`の結果であるJSONストリームを解析し、独自の属性を検証するPython/Hackベースのバリデーターのコンセプトコードだ。
// カスタム解析用ロジックの断片
function validate_integrity(AstNode $root): void {
foreach ($root->getMethods() as $method) {
// Attributeが定義されているかを確認
if ($method->hasAttribute(StrictDataIntegrity::class)) {
// ここでASTを走査し、メソッド内で禁止されている
// 変数の再代入や副作用がないかを静的に判定
if ($method->containsSideEffects()) {
// コンパイルエラーとして吐き出し、ビルドを停止させる
throw new StaticAnalysisException(
“Security Violation: Method {$method->getName()} must be immutable.”
);
}
}
}
}
この処理をCIパイプラインの`hh_client`実行直後に挟み込むことで、開発者は型エラーと同じ感覚で「ドメイン固有の規約違反」を検知できる。
4. なぜ「実行時」ではなく「静的解析」なのか
ランタイムでのチェックはメモリを消費し、仮想マシン（HHVMのJIT）に無駄な分岐命令を生成させる。
`if ($user->isAdmin()) throw …` といったコードを何百回と繰り返すことは、キャッシュラインの汚染を招き、IPC（命令数）を無駄に増大させる。
静的解析でルールを封じ込めることは、CPUにとっての慈悲である。
コンパイル時に排除された違反は、ランタイムの命令列には一切存在しない。これが、真にパフォーマンスを最適化するアーキテクトの思考だ。
5. 極限の知見：メモリとパフォーマンスへの影響
このアプローチを採用する際、一つだけ注意点がある。属性の「メタデータ」はHHVMのシリアライズされたAST内に保持されるため、極端に属性の数を増やすと、`hh_server`のメモリ消費量が跳ね上がる。
- 型チェッカーのメモリ最適化: 大規模なコードベースでは、属性の定義を必要最小限のファイルに隔離し、インデックスキャッシュの衝突を避けるべきだ。
- 型推論の高速化: 属性を用いた検証を行う際、ASTの深層探索を避け、クラスのシンボルテーブル（Symbols）のみを走査するように設計せよ。これにより、解析時間を$O(N^2)$から$O(N)$に落とし込むことができる。
—
結論
Hackにおける「厳格さ」とは、言語仕様に従うことだけではない。言語を拡張し、自らのドメインに最適な「型」を定義し、それをコンパイラに理解させることこそが、シニアエンジニアに求められる責務である。
あなたが定義したカスタム属性は、単なるメタデータではなく、コードの守護者となる。型システムの限界を突破し、HHVMの深層を掌握せよ。
次回のブログでは、`hh_client`の拡張機能をさらに深掘りし、独自の中間表現（IR）レベルでの最適化についても触れる予定だ。諸君のコードが、より堅牢なものになることを期待する。