}型変数を受け取ってPotentialBindingsを返す。受け取る型変数は代表元である必要があるっぽい。resultに対してPotentialBindingを追加したりゴニョゴニョしたりして、それをreturnする。result;ConstraintGraphから集めたConstraintに対する操作まず、ConstraintGraphからその型変数を持つConstraintを集めてくる。ConstraintGraph::GatheringKind::EquivalenceClass);そこでKindに応じて前処理的と共通の処理を行う。ここで必要ければスキップすることもある。共通処理}メインの目的は「PotentialBindingを追加すること」で、主に2つの方法で追加される。ConstraintKind::LiteralConformsToの場合はそのリテラルを表すprotocolを元にDefaultType(例えば、ExpressibleByIntegerLiteralならInt)を得て、それをPotentialBindingとして登録するSubtypeやConversionの場合は、その型自身へのPotentialBindingを登録する。重要な部分を抽出するとこんな感じ。constraint->getProtocol()});getDefaultTypeはExpressibleByIntegerLiteralはIntなど、リテラルがデフォルトで取りうる型を決める関数。}IntegerLiteralTypeなどの名前はSwift側でtypealiasが貼られている。簡単に言うと「型Tのサブクラス」という制約があったら「TへのPotentialBinding」を試す。Constraintのどっちが型変数かどうかでSubtypesかSupertypesのどちらで使えるか決まる。1つめが型変数の場合。2つめが型変数の場合。Optionalなどの細かい調整もここで行われる。PotentialBindingsの整理ConstraintGraphから集めたConstraintを一通り見終わったら、resultの整理を行う。4つの処理が行われる。LiteralProtocolはDefaultedなProtocolより優先される。LiteralProtocolがある場合はDefaultedProtocolは削除される。上のfor文で記録したdefaultableConstraintsがまだ追加されていなければPotentialBindingとして追加するaddOptionalSupertypeBindingsフラグが立っている場合はTへのBindingをT?へのBindingへ書き換える処理がされる。最後に、ここまででFullyBoundでない場合はBindingをすべて消す。まとめメインの戦略は「リテラルをデフォルトの型にする」「サブタイプなどをその型自身にする」などみたい。