HHVM型チェッカーのエラーメッセージを読み解く：型推論の失敗原因を特定する技術
聞くがいい。お前たちが日々何気なく叩いている `hh_client` の背後では、単なる文字列マッチングの構文解析など動いていない。HHVM（HipHop Virtual Machine）の型チェッカー（hh_server）は、ミリ秒単位で数百万行のAST（抽象構文木）を走査し、部分型関係（Subtyping）と連立不等式を解き続ける極限の数理エンジンだ。
特に、全ファイルを厳格モード（`<
「なぜこの共用体が解決されないのか？」
「なぜこのジェネリクスが `mixed` へと崩落したのか？」
本稿では、HHVMランタイムの内部表現と型チェッカーの推論アルゴリズムの深淵に潜り込み、型エラーの背後にある「真の矛盾」を瞬時に特定するためのデバッグ手法を伝授する。
—
1. HHVM型チェッカーの内部挙動：なぜ推論は失敗するのか
Hackの型チェッカーは、TypeScriptやFlowのような「後付けのLSP的アプローチ」ではない。HHVMのJITコンパイラと強固に結合し、ネイティブ実行時のメモリ効率を極限まで高めるために設計された「静的検証レイヤー」だ。
ローカル推論の限界と Constraint Generation
型チェッカーは、関数やメソッドの内部において Local Type Inference（局所型推論） を行う。DartやKotlinと同様に、代入された初期値から型を逆算するが、制御フロー（Control Flow Analysis: CFA）が複雑化すると、推論器は次のような罠に陥る。
1. 分岐による型の拡散（Union Type explosion）
2. invariant（非変）なジェネリックコンテナへの代入矛盾
3. `mixed` や `dynamic` への強制的なフォールバック
特にシニアエンジニアが陥りがちなのは、「人間が頭の中で描いた暗黙の型階層」と、「チェッカーが厳密に解いている代数的型システム」の乖離である。
—
2. 悪夢のエラーメッセージ：実例解剖
次のような、一見して「何が言いたいのか分からない」エラーメッセージに直面したことはないだろうか。
Inter-file dependency cycle detected or Typing error:
Typing[4110] Invalid argument [1]
-> Expected `vec
-> But got `vec
このエラーそのものは初歩的に見えるかもしれないが、これがジェネリクスや形状（Shape）、そして共変性（Covariance）／反変性（Contravariance）が絡み合う複雑なコードベースで発生したとき、多くの開発者はパニックに陥り、無意味に `HH\Asio\join` を挟んだり、`HH_FIXME` でエラーを握りつぶしたりする。
それはエンジニアの恥だ。型チェッカーの吐き出すメッセージを「逆算」し、コードのどこに論理的破綻があるのかを構造化して暴く方法を見ていこう。
—
3. 型推論の破綻を再現するコードとデバッグ戦略
以下の実用的なHackコードを見てほしい。ここで、意図的な型推論の失敗と、それに対するチェッカーの挙動、そして正しい修正アプローチを解説する。
<
namespace HackArchitect\Core;
// 厳密なドメインモデルを定義
interface IEntity {
public function getId(): int;
}
final class UserEntity implements IEntity {
public function __construct(private int $id, private string $name) {}
public function getId(): int { return $this->id; }
public function getName(): string { return $this->name; }
}
final class OrderEntity implements IEntity {
public function __construct(private int $id, private float $amount) {}
public function getId(): int { return $this->id; }
public function getAmount(): float { return $this->amount; }
}
// リポジトリクラス：ジェネリクスの不変性（Invariance）の罠
class Repository
private vec
public function __construct(vec
$this->items = $initialItems;
}
public function add(T $item): void {
$this->items[] = $item;
}
// 【バグの温床】このメソッドの型シグネチャに注目せよ
public function merge(Repository
// ここで型チェッカーは怒り狂う
foreach ($other->getItems() as $item) {
$this->add($item);
}
}
public function getItems(): vec
return $this->items;
}
}
このコードを `hh_server` に通したとき何が起きるか？
`merge` メソッド内の `$this->add($item);` において、HHVM型チェッカーは次のようなエラーを吐き出す。
Typing[4110] Invalid argument
-> Expected `T` (is a `HackArchitect\Core\IEntity`)
-> But got `IEntity`
なぜこのエラーが発生するのか？（低レイヤの数理的解説）
1. `Repository
2. `$other` は `Repository
3. 一方、呼び出し元の `$this` が `Repository
4. しかし、`$other` から取り出された `$item` は抽象的な `IEntity` であり、中身が `OrderEntity` である可能性を排除できない。
5. したがって、チェッカーはメモリ安全性（Type Safety）を担保するため、「`IEntity` を `UserEntity` のスロットに突っ込むな」というエラー（Typing[4110]）を強制する。
これが、型推論とサブタイピングの矛盾の正体だ。
—
4. 限界を突破する：型システムを正しく調停する技術
この問題を解決するには、Hackの型システムの挙動（特に変性: Variance）を正確にコントロールする必要がある。
修正アプローチ：共変性（Covariance）の活用と型制約の再設計
もし読み取り専用のコレクションであれば、`+` アノテーションを用いて 共変（Covariant） を明示し、安全なアップキャストを許可すべきだ。しかし、ミュータブルな要素追加がある場合は、ジェネリクスの境界（Bounded Quantification）を適切に定義しなければならない。
次のように書き換えることで、型チェッカーの矛盾を解消しつつ、厳格モードの恩恵を最大化できる。
<
namespace HackArchitect\Core;
interface IEntity {
public function getId(): int;
}
// 修正されたリポジトリ：型安全なマージ処理
class Repository
private vec
public function __construct(vec
$this->items = $initialItems;
}
public function add(T $item): void {
$this->items[] = $item;
}
// ジェネリックメソッドとして再定義し、型パラメータを安全に伝搬させる
public function merge
// Tu は T のサブタイプ（または同一）であることが保証されているため、
// $this->add() への代入は完全に安全であると型チェッカーが証明できる。
foreach ($other->getItems() as $item) {
$this->add($item);
}
}
public function getItems(): vec
return $this->items;
}
}
修正のメカニズム
`merge(Repository
—
5. チーフアーキテクトからの提言：型エラーを恐れるな
エラーメッセージは、お前たちの敵ではない。それは、HHVMのランタイムが「お前のコードには論理的な穴があり、このままではネイティブマシン語へのコンパイル時に安全性を保証できない」と叫んでいる、極めて精緻な警告シグナルなのだ。
1. エラーコード（例: `Typing[4110]`）の構造を覚えろ。 期待値（Expected）と実際（Got）の乖離の根源が、どのスコープのどのジェネリクスに起因するのかをASTのツリー構造で脳内トレースしろ。
2. `dynamic` や `mixed` に逃げるな。 それは型システムへの敗北であり、HHVMのJIT最適化の恩恵をドブに捨てる行為に等しい。
3. 境界（Bounds）と変性（Variance）を支配しろ。
Hackの厳格モードを使いこなすということは、コンパイラと対話しながら、数学的に完璧なデータ構造を構築するということだ。その極限の領域に到達したとき、お前たちの書くコードは、PHPの皮を被った世界最高峰の高速・堅牢なシステムへと昇華される。
コードを書け。そして、チェッカーをねじ伏せろ。