現在のReader.readは Moduleを返しているが、これはReaderのプロパティにそのまま生えてるmoduleと同一であり、情報としては嬉しくない。 その1回のreadで読み取った型などのセットを返してあげると、使う側でファイルやディレクトリ単位で読み込まれたものを管理できて便利だと思いました。

SType は型宣言それ自体と型参照が隠蔽されているので使いづらい。

Swiftの意味論をうまくコードで表現する設計としては、 本家コンパイラの実装が参考になる。

最近出版されたSlavaの本 (https://forums.swift.org/t/compiling-swift-generics-part-i/60898) は、 それを学ぶためにとても役に立つ。 この本をガイドにしつつ、コンパイラのソースを読む事で、理解を深める事ができそうだ。

ある程度深まったら、参考にして大改修する。

やったこと

現在 Modules となっている型を変更する。 Readerの出力はContextに影響を与える。

現在はModulesをweakで保持していて、 それがnilの場合に例外を投げているが、 それがあちこちに伝搬してよくわからないthrowsがはびこっている

Modulesの生存を管理するのはプログラマ責任で、 動的な入力に依存しないので、 論理バグと考えてクラッシュするように変更する。

APIの変化

従来は、指定しない場合 Modules が自動で作られ、Reader.read から返されていた。 これをretainしないと例外が飛んだりした。

新仕様では、Contextの生成は明示的に必要とした。

他でやること

Locationは宣言レベルの構造を規定するので、 ソースコードは必ずモジュールに所属してるため、 必ずモジュールはまず持っている。 これを静的に表現する。

下記コードにおいて、

struct G<T> {
  struct A {}
}

G<X>.A と G<Y>.A は型システムにおいて異なる型だが、 現状の設計だと表現できない。

Location という似たようなコンセプトが導入されているが、 これは記述的な宣言レベルの構造を表す情報なので、型パラメータを取れない。

例えば上記の場合、 A を表す SType の location は、 main.G になっているが、型パラメータは持たない。

一方、TypeSpecifier というコンセプトがある。 これは型参照なのでパスにパラメータを埋められるので、 main.G<X>.A といった表現を持てる。

しかし、このジェネリックコンテキスト付きのパス情報は SType 自身には付与できない。

SType には genericArguments プロパティで自身のジェネリック引数を表現するコンセプトがある。 ここで、パラメータ型とコンクリート型は、SType で統合されていて、 パラメータを取る型の状態と、パラメータが埋まった状態を表現できる。

例えば、 G<GenericParameterType(T)> の状態はパラメータを取る前のジェネリックな型を表現している。 G<StructType(X)> はパラメータを受け取った後の具体化された型を表現している。

ジェネリックコンテキストの表現は難しいが、 LocationElement.type が型パラメータ引数も表現できるようにしてしまえば一応表せる。

Location が記述的なコンセプトだったが、 意味的なコンセプトに拡張されることになる。 なにか問題は無いだろうか・・・？

Issue

Xcode 14.0 beta (14A5228q) 及びSwift 5.7でBinarySwiftSyntaxが利用できなくなった。（ https://github.com/omochi/BinarySwiftSyntax/issues/5 ） その影響でこのパッケージもビルドできなくなっている。

Fix

本家のSwiftSyntaxを使う。

本家のSwiftSyntaxは最新のリリースから _InternalSwiftSyntaxParser.dylib を同梱するようになり、実行環境のXcodeに依存しなくても良くなった。

https://github.com/apple/swift-syntax/releases/tag/0.50600.1

課題

TypeResolver が型を探索する際、すでに読み込み済みの他モジュールの型情報を探索してくれない問題を修正します。 具体的には、下記のようなモジュール構成の場合に、main.P.f の返り値である E の型情報が読み取れなくなっています。 E の型名だけは取り出せるのでこれまでは課題が顕現しませんでしたが、 E がenumかどうか、の検証を始めると課題が浮かび上がりました。

// MyLib モジュール
public enum E {
   case a
}

// main モジュール
import MyLib

protocol P {
   func f() -> E
}

解決方法

現状では Swift モジュールだけハードコードで探索されている部分を自身の親 Modules 全体を読み込むように変更します。

その他

課題はこれで解決しますが、依然厳密さは足りていない状況で、ファイル単位での import declの有無を検証しないため、本来import文が不足していて読み取れないはずの型を読み取れてしまうことがあります。 現状のSwiftTypeReaderではファイル単位で型定義のスコープを管理する仕組みがないので、これは一旦諦めて Modules に読み込まれたモジュールは全てimportされているという前提ということにしています。

https://github.com/omochi/SwiftTypeReader/pull/7#discussion_r743528385 への対応です。

BinarySwiftSyntax側のmainブランチにSwiftSyntax-Xcode13.0が生えてから正しく動作可能になります。 PR: https://github.com/omochi/BinarySwiftSyntax/pull/3

exclude: ["Resources"] はResourcesディレクトリがそのそも存在しなくて警告が出ていたので削除しました。

TypeLocはコンパイラ内部で利用されているTypeReprもしくはTypeを保持する型。

多くの場合にはTypeReprとして機能しているが、 コンパイラ内部ではDeclを動的に構成する際に、 手元の解決済みの型を直接設定する場合に使われている。

知る限りでは、Protocolの Self 型の conformance protocol として プロトコル自身を設定するところで、 プロトコル型を直接埋め込んでいた。

しかし、動的に構成可能で、TypeReprで表現できない型は存在しないように思われるので、 そこに型があるならTypeReprで表現して格納できると思う。

その方がデータ構造がシンプルになり理解しやすいので、 いったん削除してみる。

asStruct などのキャストプロパティを追加します。

as? 演算子は、 as? any NominalTypeDecl と書くべきところで as? any NominalType と書いてしまうなどのミスが生じたり、 Xcodeが変換候補を提供しない、式を丸括弧で包む必要がある、などの欠点があります。

それを補うため、補間によって候補を列挙したり、入力ミスをしない方法を提供します。

本家Swiftコンパイラを参考にデータ構造を組み替える

依存値のキャッシュ計算＋サイクル検出はc2tsでも必要になったので、 Request Evaluatorを導入する

~~コンパイラと違ってレジリエンスは要らないため、 エラー値は導入しない事にする。 不正なコードが入力されて意味解決に問題がある場合、例外で停止する。 Requestの依存があるのでほとんどがthrowsになるだろう。~~

SwiftTypeReaderのレイヤーだと、不明な型はそのまま通したほうが扱いやすい。 後段のC2TSのレイヤーで、エラーにするとかtypeMapですり替えるとか、 そういう対応がありえる。

型推論の未解決型変数に unresolved type が使われているので、 type reprの未解決は unknown type に名前を変更する。

Typeは値型にしてみる。 本家同様にimmutable classにした場合と比べると、 キャッシュのキーに使う場合にハッシュ計算コストがかかってしまう。 逆にimmutable classは生成時にキャッシュを通す必要が生じるが、 依存値を引く時のキャッシュはポインタで済む。

Declはクラスにしてツリー構造を表現する。 parentへの弱参照も入れる。 こうすることでLocationで無理する必要がなくなる。

DeclはASTインスタンスであり、 静的なオブジェクトになる。

Typeは必要に応じてDeclを参照する。 概ねそれ＋GenericArg だけのオブジェクトになる事が多いだろう。

NominalとBoundGenericNominalの区別は入れない。 必要ないと思うんだよな。 シンプルに済ませられる。

Reprも値型にしてみる。 これこそキャッシュを考えるとclassが望ましいが・・・

archetypeは導入しない 難しそうなので なくても十分な気がする

ASTScopeは導入しない Decl treeだけでいけるきがする

TypeReprも読めない可能性がある。 そういう場合に、そういうフィールドだけ読み飛ばすほうがマシなので、 やはりレジリエンスは必要・・・

需要

読み取ったソースコードが他モジュールへのimport文を持っていた場合に、コード生成した結果のファイルにも同様のimport文を書きたくなるときがある。

例:

• Entityモジュール

public struct UserID {}

• APIDefinitionモジュール

import Entity

public protocol FooServiceProtocol {
    func foo() -> UserID
}

• 生成コード

// import Entity（ここにimportをいい感じに書けるようにしたい）

struct FooProvider {
    func foo() -> UserID { ... } // compile error! UserID is not found
}

解決方法

Module から、そのモジュールがimportしている定義を取得できるようにする

悩み

• SwiftTypeReaderは名前的にはTypeを読み取るのが仕事であるため、importDeclを読み込みのは責務を超えている？
  • このような微妙に手が届いてないケースにはコード生成コードがSwiftSyntaxを直接使うべき？
  • あるいは利便性を考慮してSwiftTypeReaderで読めるようにしてあげるべき？

extensionがあると、

struct GenericID<T> {}

extension GenericID: Codable where T: Codable {}

というパターンが正しく認識できるようになる。 conditional conformanceを解決するのは、 associated typeの解決もある場合、難しすぎるけど・・・