コンパイラのチャンネルを作りました

2

3

12:38 PM

$ swift -Xfrontend -emit-ir -Xllvm -debug a.swift -Xllvm -debug をつけると、 LLVM_DEBUG で吐かれてるいろんなデバッグ情報が、出てくるんですね。

https://github.com/apple/swift/blob/master/docs/SILProgrammersManual.md

apple/swift

swift - The Swift Programming Language

1

7:01 AM

コンパイラコードの解説

7:01 AM

SIL関数がLoweringで引数のインデックスがずれる話などが書かれてる

7:02 AM

他の領域についても書いていきたい感じのようなので、助かる

TBDのところを早く書いてほしい！

Guaranteed Optimization 無しでコンパイルするオプションみたいなの無いですか？

それは聞いたことないなー。特定のPASS限定で最適化するオプションなら知ってますけど

protocol P { associatedtype T func f(_ g: @escaping (T) -> Void) } class C<S>: P { typealias T = S private let _f: ((S) -> Void) -> Void init<Q: P>(q: Q) where Q.T == T { // Error: cannot assign value of type '((S) -> Void) -> Void' to type '((S) -> Void) -> Void' self._f = { g -> Void in q.f(g) } } func f(_ g: @escaping (S) -> Void) { self._f(g) } }

でエラーメッセージが不親切な件の原因を探している過程で、意図のわからないコードがあったので質問させてください

 // Try to simplify irrelevant details of function types. For example, if // someone passes a "() -> Float" function to a "() throws -> Int" // parameter, then uttering the "throws" may confuse them into thinking that // that is the problem, even though there is a clear subtype relation. if (auto srcFT = exprType->getAs<FunctionType>()) if (auto destFT = contextualType->getAs<FunctionType>()) { auto destExtInfo = destFT->getExtInfo(); if (!srcFT->isNoEscape()) destExtInfo = destExtInfo.withNoEscape(false); // 👈

ですが、これコメントの通り関数の型の不一致に escaping とか throws とか混ぜるとややこしいので出さない的な意図であってそうでしょうか？ https://github.com/apple/swift/blob/5e7da0e3dcf13c603233c1f2aad1f1aded8821df/lib/Sema/CSDiag.cpp#L3250

apple/swift

swift - The Swift Programming Language

11:38 AM

https://github.com/apple/swift/blob/5e7da0e3dcf13c603233c1f2aad1f1aded8821df/lib/Sema/CSDiag.cpp#L3261

apple/swift

swift - The Swift Programming Language

11:38 AM

あれ、ちょっと思ってたのと違うな… この分岐で拾われているように見える

11:45 AM

コードリーディングだけだとちょっとつらいですね…これ実際に swiftc を debug build して見ないとすぐにはわからなさそう…

https://twitter.com/kateinoigakukun/status/1027189762254204930

こっちですね

kateinoigaku (@kateinoigakukun)

swiftcのlldbでdumpメソッドが使えなくて困ってる

@Yuta Saito とりあえず、 Step Into で dump() の中に潜ってみたら？

コード上のdump()は動いてました

何も出力されないのが正しい挙動の可能性も。

https://github.com/apple/swift/blob/master/docs/DebuggingTheCompiler.rst#dumping-the-sil-and-other-data-in-lldb

apple/swift

swift - The Swift Programming Language

3:49 PM

SILのinstructionは少なくともdumpできるっぽいですね

今手元でビルドしてるから通ったら試してみる

3:49 PM

(さっきから3回失敗した

1

ありがとうございます！

3:52 PM

a

3:53 PM

Xcodeのlldbに出力されると思っていたんですけど、

うわ、またこけた

3:53 PM

あｗ

3:53 PM

そこかｗ

3:53 PM

アタッチしてるならプロセスのほうのコンソールに出るよ！

なるほどーーーーーーーーー

それなｗ

wait for executable to be launchedだ

3:54 PM

盛大に勘違いしてました

@Kuniwak エラーが不親切な件を調べてみました。直接の原因はわかりました。根っこの原因は、Sema(型推論)モジュールのバグではないか、というところまで推測したところです。下記にわかったことを整理しています。 CC: @rintaro @ukitaka

2

5:07 AM

https://gist.github.com/omochi/c2e32ca157fa70dc2a76c46e8fd6d7d7

bad-conv-warn.md

o,

5:54 AM

なんと、とりあえず gist 読みます

5:56 AM

なるほどーーーーー

はい、なので根っこの問題は、 AnyFunctionType exprType が構成された時点でもう発生していて

5:57 AM

推論させたかどうかで変わるので、推論器にバグがあるんじゃないかなあ、というところ。

Sema読んだこと全く無くて全く取っ掛かりがわからんｗ

制約アルゴリズムの中でブレークしても何がなんだかわからんな・・・

尻尾つかみそう

[omochi@omochi-iMac-PC43 warn]$ swift aaa.swift aaa.swift:16:9: error: cannot assign value of type '(@escaping (Int) -> Void) -> Void' to type '((Int) -> Void) -> Void' f = { (g) -> Void in ^~~~~~~~~~~~~~~~

10:48 AM

なおせたかもしれん。

10:49 AM

めちゃくちゃ闇が深い

むむむ・・・

6:51 PM

タプルの中に関数が入っている場合や、オプショナルの中に関数が入っている場合などは

6:51 PM

@escaping が暗黙に確定しているんだけど

6:52 PM

そのような型が絡んだ型マッチエラーの場合に

6:52 PM

暗黙だった @escaping が、明示された形で表示されるようになってしまう副作用が出てきた・・・

https://github.com/apple/swift/pull/18142

[AST] explicit PrintOptions default constructor by omochi · Pull ...

This PR add default constructor of PrintOptions explicitly. This is already implemented by c++ compiler implicitly. But, it can not be called from lldb session. (lldb) p f->getLoweredFunctionTyp...

3:41 AM

↑この前のやつ、また困ったのでゴネたら許された

4

lldbでラムダ式の中とかにいる時に、外側のスコープの変数にアクセスする方法ってありますか？

5:10 AM

ラムダ式の実装の匿名クラスが this を shadow してしまって、困る

5:11 AM

XcodeのGUIのほうだとなんか見れるからできそうなんだけども・・・

[&]なラムダ式ってことでいいんでしょか？

Type Solution::simplifyType(Type type) const { if (!type->hasTypeVariable()) return type; // Map type variables to fixed types from bindings. return simplifyTypeImpl( getConstraintSystem(), type, [&](TypeVariableType *tvt) -> Type { auto known = typeBindings.find(tvt); assert(known != typeBindings.end()); return known->second; }); }

5:14 AM

↑ここで、 known->second の行にいるときに

5:14 AM

Solution::getConstraintSystem->dump() したい

もし普通にやって見えないなら、スタック降りれば見えないですか？

あーたしかに、 [&] でのthisの暗黙ミュータブルキャプチャですね、

5:15 AM

あ〜〜〜

5:15 AM

まあたしかに・・・

5:15 AM

普通にやると、 this はラムダ式自身になってしまっていて

5:15 AM

見えないんですよね

5:16 AM

xcodeだとthisがプルダウンできて、そうするとその中にもう一度thisがあって、見えるんですけど

5:16 AM

同じように this->this-> ってかいても、

5:16 AM

error: expected unqualified-id

5:16 AM

になってしまいます

5:17 AM

内側にthisがあるのはラムダキャプチャーしてそういうフィールド名が生えてるのかな・・・

5:17 AM

今回のケースはエスケープしてないからたしかにスタック戻れば見れますね。

ラムダ式の中でthis使ってないから参照が生きてないのかな・・・

typeBindingsは this->typeBindingsの略記なんですよね

5:20 AM

Xcodeのほうでも出てるから、できそうなんだけど・・・

Xcodeのツリーは fr variable だと思うので、ちょっと違うんですよねー

ふむふむ

下書きだけど、なんとか望んだ挙動をするパッチができた、testも通った

よくわからない変数名の短縮のノリがわからなくて

12:10 PM

スタイルを寄せられない・・・

ノリで大丈夫っす！

1

ぐわーーだめだーーー

2:45 PM

あと少しのところまで行ったけどその作戦じゃ別の場所が破綻してだめだった

https://gist.github.com/omochi/d8bcc8dbdd7bddf390839ba035a3258a 遺書です

bad-conv-report.md

2

今のmasterは FunctionType の入力が TupleType/ParenType だったのを FunctionType にパラメータリストを持たせるようにしていく過渡期なので、ここに手をだすのは危険だったかもしれないですね。

そうなんですね、ついでに直ってほしいな・・・チケットはたてといた https://bugs.swift.org/plugins/servlet/mobile#issue/SR-8499

1

// RefBox.value.modify sil hidden [transparent] @$S1a6RefBoxC5valuexvM : $@yield_once @convention(method) <T> (@guaranteed RefBox<T>) -> @yields @inout T { // %0 // users: %2, %1 bb0(%0 : $RefBox<T>): debug_value %0 : $RefBox<T>, let, name "self", argno 1 // id: %1 %2 = ref_element_addr %0 : $RefBox<T>, #RefBox.value // user: %3 %3 = begin_access [modify] [dynamic] %2 : $*T // users: %5, %8, %4 yield %3 : $*T, resume bb1, unwind bb2 // id: %4 bb1: // Preds: bb0 end_access %3 : $*T // id: %5 %6 = tuple () // user: %7 return %6 : $() // id: %7 bb2: // Preds: bb0 end_access %3 : $*T // id: %8 unwind // id: %9 } // end sil function '$S1a6RefBoxC5valuexvM'

6:11 AM

今のmasterで、コルーチンによるmodifyアクセサが生成されるようになっている

6:14 AM

再開したらresume, 中止したらunwind

6:14 AM

中止ってなんやねん

modify(&x.b) で modify 内で結局書き換わらなかったときかな？

struct IntBox { var value: Int = 3 } func mod(_ value: inout Int) { value *= 2 } var box = IntBox() mod(&box.value)

6:22 AM

今これを試してみたんですが、 modifyが使用される形にはならなかった。

protocol HasInt { var intValue : Int {get set} } func mod(_ val: inout Int) throws {} func testing<T: HasInt>(x: inout T) throws { try mod(&x.intValue) }

6:58 AM

で、

// testing<A>(x:) sil hidden @$S4test7testing1xyxz_tKAA6HasIntRzlF : $@convention(thin) <T where T : HasInt> (@inout T) -> @error Error { // %0 // users: %3, %1 bb0(%0 : $*T): %3 = begin_access [modify] [static] %0 : $*T // users: %11, %16, %5 %4 = witness_method $T, #HasInt.intValue!modify.1 : <Self where Self : HasInt> (inout Self) -> () -> () : $@yield_once @convention(witness_method: HasInt) <τ_0_0 where τ_0_0 : HasInt> (@inout τ_0_0) -> @yields @inout Int // user: %5 (%5, %6) = begin_apply %4<T>(%3) : $@yield_once @convention(witness_method: HasInt) <τ_0_0 where τ_0_0 : HasInt> (@inout τ_0_0) -> @yields @inout Int // users: %8, %10, %15 // function_ref mod(_:) %7 = function_ref @$S4test3modyySizKF : $@convention(thin) (@inout Int) -> @error Error // user: %8 try_apply %7(%5) : $@convention(thin) (@inout Int) -> @error Error, normal bb1, error bb2 // id: %8 bb1(%9 : $()): // Preds: bb0 end_apply %6 // id: %10 end_access %3 : $*T // id: %11 %12 = tuple () // user: %13 return %12 : $() // id: %13 // %14 // user: %17 bb2(%14 : $Error): // Preds: bb0 abort_apply %6 // id: %15 end_access %3 : $*T // id: %16 throw %14 : $Error // id: %17 } // end sil function '$S4test7testing1xyxz_tKAA6HasIntRzlF'

なので、アクセス中に throw したときみたいです。

お

6:33 AM

struct Stone { var _x: Int = 3 var x: Int { get { return _x } _modify { yield &_x } } } func mod(_ x: inout Int) { x = 8 } func main() { var a = Stone() mod(&a.x) }

6:33 AM

define hidden swiftcc void @"$S1a4mainyyF"() #0 { entry: %a = alloca %T1a5StoneV, align 8 %0 = bitcast %T1a5StoneV* %a to %swift.opaque** store %swift.opaque* null, %swift.opaque** %0, align 8 %1 = alloca [32 x i8], align 8 %2 = bitcast %T1a5StoneV* %a to i8* call void @llvm.lifetime.start.p0i8(i64 8, i8* %2) %3 = call swiftcc i64 @"$S1a5StoneVACycfC"() %a._x = getelementptr inbounds %T1a5StoneV, %T1a5StoneV* %a, i32 0, i32 0 %a._x._value = getelementptr inbounds %TSi, %TSi* %a._x, i32 0, i32 0 store i64 %3, i64* %a._x._value, align 8 %4 = getelementptr inbounds [32 x i8], [32 x i8]* %1, i32 0, i32 0 call void @llvm.lifetime.start.p0i8(i64 32, i8* %4) %5 = call swiftcc { i8*, %TSi* } @"$S1a5StoneV1xSivM"(i8* noalias dereferenceable(32) %4, %T1a5StoneV* nocapture swiftself dereferenceable(8) %a) %6 = extractvalue { i8*, %TSi* } %5, 0 %7 = extractvalue { i8*, %TSi* } %5, 1 call swiftcc void @"$S1a3modyySizF"(%TSi* nocapture dereferenceable(8) %7) %8 = bitcast i8* %6 to void (i8*, i1)* call swiftcc void %8(i8* noalias dereferenceable(32) %4, i1 false) call void @llvm.lifetime.end.p0i8(i64 32, i8* %4) %9 = bitcast %T1a5StoneV* %a to i8* call void @llvm.lifetime.end.p0i8(i64 8, i8* %9) ret void }

6:33 AM

define hidden swiftcc { i8*, %TSi* } @"$S1a5StoneV1xSivM"(i8* noalias dereferenceable(32), %T1a5StoneV* nocapture swiftself dereferenceable(8)) #1 { entry: %._x = getelementptr inbounds %T1a5StoneV, %T1a5StoneV* %1, i32 0, i32 0 %2 = insertvalue { i8*, %TSi* } { i8* bitcast (void (i8*, i1)* @"$S1a5StoneV1xSivM.resume.0" to i8*), %TSi* undef }, %TSi* %._x, 1 ret { i8*, %TSi* } %2 } define internal swiftcc void @"$S1a5StoneV1xSivM.resume.0"(i8* noalias nonnull dereferenceable(32), i1) #0 { entryresume.0: %FramePtr = bitcast i8* %0 to %"$S1a5StoneV1xSivM.Frame"* %vFrame = bitcast %"$S1a5StoneV1xSivM.Frame"* %FramePtr to i8* ret void }

6:34 AM

テストコードみてたら、 _modify でもうお試しできるとわかった

ほう。

@swift-main

struct Stone { var x: Int { get { return 1 } _modify { var x: Int = 3 yield &x y = x } } var y: Int = 0 } func mod(_ x: inout Int) { x = 8 } func main() { var a = Stone() mod(&a.x) print(a.y) } main()

8

ローカル変数のアドレスをreturn！(yield

6:46 AM

resume.0とか関数が作られてるってことは

6:46 AM

ステートマシン変換型じゃなくて

6:46 AM

復帰先を、都度関数ポインタで返してるから、CPS変換型って感じ？

スタックフレームの代わりにフレーム用のメモリ領域を引数で取り回していて、そのサイズは32バイト, フレームがそれよりでかい場合は、malloc/freeでサイドアロケートするっぽい

コンパイラのコンパイルが通らないのですがどなたか助けていただけませんか

/Users/hiragram/Development/swift-source/swift/stdlib/public/SDK/Intents/INIntent.swift:25:19: error: value of type 'INIntent' has no member '__setImage'; did you mean 'setImage'? (self as! INIntent).__setImage(image, forParameterNamed: keyPathString) ~~~~~~^~~~~~~~~~~~~ ~~~~~~~~~~ setImage Intents.INIntent:10:15: note: 'setImage' declared here open func setImage(_ image: INImage?, forParameterNamed parameterName: String) ^ /Users/hiragram/Development/swift-source/swift/stdlib/public/SDK/Intents/INIntent.swift:23:17: note: 'setImage' declared here public func setImage<Value>(_ image: INImage?, forParameterNamed parameterName: KeyPath<Self, Value>) { ^ /Users/hiragram/Development/swift-source/swift/stdlib/public/SDK/Intents/INIntent.swift:32:26: error: value of type 'INIntent' has no member '__image'; did you mean 'image'? return (self as! INIntent).__image(forParameterNamed: keyPathString) ~~~~~~^~~~~~~~~~~~~ ~~~~~~~ image Intents.INIntent:12:15: note: 'image' declared here open func image(forParameterNamed parameterName: String) -> INImage? ^ /Users/hiragram/Development/swift-source/swift/stdlib/public/SDK/Intents/INIntent.swift:30:17: note: 'image' declared here public func image<Value>(forParameterNamed parameterName: KeyPath<Self, Value>) -> INImage? { ^ [973/1575] Compiling /Users/hiragram/Development/swift-source/build/Ninja-ReleaseAssert/swift-macosx-x86_64/stdlib/public/SDK/Foundation/macosx/x86_64/Foundation.o ninja: build stopped: subcommand failed. utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting

2:15 PM

https://qiita.com/rintaro/items/2047a9b88d9249459d9a rintaroさんの記事をなぞっているんですけど

Swiftコンパイラ開発環境構築 - Qiita

Swift がオープンソースになってしばらく経ちます。コンパイラや標準ライブラリの開発に手を出してみたいけど、リポジトリを落とした後どうしていいかわからない！という方のために、まずは開発環境...

2:15 PM

utils/build-script -Rt これでこうなる

Xcode のバージョンは何ですか？また、xcode-select されてますか？

Xcode10bです

2:17 PM

あ　最新ではないかも

これ

Version 10.0 beta (10L176w)

もっと上の方にエラーがあると思う

リポジトリ構成

swiftコンパイラプロジェクトは、複数のリポジトリから構成されています。その中で主役となるのが[apple/s...

12:41 AM

スキーマが作成できたら、ビルドや実行をする前に、スキーマのBuild Configurationをビルドバリアントと同じものに設定する必要があります。

ああー　それっぽい　2時半で見落としてたやありがとう

これ自分含め何人も踏んでる (edited)

mutableAddressWithNativeOwnerから_modifyへ https://github.com/apple/swift/pull/19154

[stdlib] Update Array.subscript to use _modify by airspeedswift ·...

This switches Array from using mutableAddressWithNativeOwner to using a yielding _modify

もともとそんな謎アクセサがｗ

@sil_name(hoge) みたいな、「SIL上に現れる名前はこっちにする」的なやつなかったでしたっけ(前にどっかで見たような気がするけど見つけられない)

@swift-4.1.3 -frontend -emit-sil @_silgen_name("hoge") func f() {}

sil_stage canonical import Builtin import Swift import SwiftShims @_silgen_name("hoge") func f() // main sil @main : $@convention(c) (Int32, UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>) -> Int32 { bb0(%0 : $Int32, %1 : $UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>): %2 = integer_literal $Builtin.Int32, 0 // user: %3 %3 = struct $Int32 (%2 : $Builtin.Int32) // user: %4 return %3 : $Int32 // id: %4 } // end sil function 'main' // hoge sil hidden @hoge : $@convention(thin) () -> () { bb0: %0 = tuple () // user: %1 return %0 : $() // id: %1 } // end sil function 'hoge'

あ、それです…　ありがとうございます

へえ〜そんなのが。

lazy var hogeすると hoge.storageという名前のstorageがsilに現れるのでなんか適当な他のプロパティを @_silgen_name("hoge.storage") したらおかしくならないかな〜と思ってやりたくなったけど型のプロパティに対して付けられなかった

コンパイラ都合で作られる何かしらのもの、ドット区切りでネームスペース風にしてるのをほかのところでも見る (edited)

2:19 AM

プロパティの名前はそのまま関数名になるわけじゃないから、varに対してはつけられなそうだね

2:20 AM

varに対応して生成されるgetterと衝突するsil名を別の関数に与えておく事はできそう

@swift-4.1.3 struct A { var b: Int = 1 @_silgen_name("_T04hoge1AV1bSivg") func itazura() -> Int { return 2 } }

no output

@swift-4.2.4 struct A { var b: Int = 1 @_silgen_name("_T04hoge1AV1bSivg") func itazura() -> Int { return 2 } }

2:30 AM

帰ってこない

2:31 AM

@swift-4.1.3

struct A { var b: Int { return 1 } @_silgen_name("_T04hoge1AV1bSivg") func itazura() -> Int { return 2 } } print(A().b) print(A().itazura())

1 2

@swift-4.2.4

struct A { var b: Int { return 1 } @_silgen_name("_T04hoge1AV1bSivg") func itazura() -> Int { return 2 } } print(A().b) print(A().itazura())

2:31 AM

帰ってこない

2:31 AM

#swiftbot-sandbox こっちでやります

またXcodeでコンパイル通らなく鳴った

no such file or directory: '/Users/hiragram/Development/swift-source/build/Xcode-RelWithDebInfoAssert/cmark-macosx-x86_64/src/Release/libcmark.a'

4:18 PM

今日はねます

libcmark.aが見つからないのはスキーム間違えてるやつよ

utils/build-script --xcode --release-debuginfo がこういう死に方するの何だろう

Assertion failed: (FD >= 0 && "File not yet open!"), function preferred_buffer_size, file /Users/hiragram/Development/swift-source/llvm/lib/Support/raw_ostream.cpp, line 701.

それなんだっけな

4:39 PM

運だった気も

2回cleanしたけど2回コケて心折れそう

4:45 PM

3かいめしてる

クリーンは

4:45 PM

フォルダごと消してる？

buildフォルダごとけした

うーんじゃあハズレコミットかなあ

4:46 PM

0908snapshotが

4:46 PM

昨日ビルドできたよ

4:48 PM

あと

4:48 PM

—skip-build-benchmarksをオススメする

お

コンパイラがジョブをプロセス分離してposix_spawnするパターンにあたってしまって

1:22 PM

デバッグができなくて困った

xcodeのlldbコンソールからdetachした後で、

2:44 PM

Debug > Attach to Process で

2:44 PM

スポーンされてるサブプロセスにアタッチしてやれば

2:44 PM

一応できた・・・

2:44 PM

ただしブレークする猶予は無い

frontend が posix_spawn するのですか？

はい

2:52 PM

/usr/local/bin/python /Users/omochi/work/swift-source/swift/utils/line-directive \ @/Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/stdlib/public/core/WkKut.txt -- \ /Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/./bin/swiftc -c \ -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk \ -target x86_64-apple-macosx10.9 \ -resource-dir /Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift \ -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/../../../Developer/Library/Frameworks \ -Onone -g -D INTERNAL_CHECKS_ENABLED -D SWIFT_ENABLE_RUNTIME_FUNCTION_COUNTERS \ -I /Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift/macosx/x86_64 \ -module-cache-path /Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/./module-cache -no-link-objc-runtime \ -Xfrontend -enable-resilience -nostdimport -parse-stdlib -module-name Swift \ -Xfrontend -group-info-path -Xfrontend /Users/omochi/work/swift-source/swift/stdlib/public/core/GroupInfo.json \ -swift-version 5 -warn-swift3-objc-inference-complete -Xfrontend -verify-syntax-tree \ -Xllvm -sil-inline-generics -Xllvm -sil-partial-specialization -Xfrontend -enable-sil-ownership \ -Xcc -DswiftCore_EXPORTS -warn-implicit-overrides -module-link-name swiftCore -force-single-frontend-invocation \ -Xcc -D__SWIFT_CURRENT_DYLIB=swiftCore -parse-as-library \ -o Swift.o \ @/Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/stdlib/public/core/WkKut.txt

(edited)

2:52 PM

元のコマンドはこれで

2:53 PM

C->performJobs に入って、その中で posix_spawnに到達します

2:55 PM

#0 0x00000001033edfaa in swift::sys::Task::execute() at /Users/omochi/work/swift-source/swift/lib/Basic/Unix/TaskQueue.inc:198 #1 0x00000001033f0301 in TaskMonitor::beginExecutingATask(swift::sys::Task&) at /Users/omochi/work/swift-source/swift/lib/Basic/Unix/TaskQueue.inc:504 #2 0x00000001033eebf3 in TaskMonitor::startUpSomeTasks() at /Users/omochi/work/swift-source/swift/lib/Basic/Unix/TaskQueue.inc:477 #3 0x00000001033ee7a3 in TaskMonitor::executeTasks() at /Users/omochi/work/swift-source/swift/lib/Basic/Unix/TaskQueue.inc:451 #4 0x00000001033f106f in swift::sys::TaskQueue::execute(std::__1::function<void (int, void*)>, std::__1::function<swift::sys::TaskFinishedResponse (int, int, llvm::StringRef, llvm::StringRef, swift::sys::TaskProcessInformation, void*)>, std::__1::function<swift::sys::TaskFinishedResponse (int, llvm::StringRef, llvm::StringRef, llvm::StringRef, void*, llvm::Optional<int>, swift::sys::TaskProcessInformation)>) at /Users/omochi/work/swift-source/swift/lib/Basic/Unix/TaskQueue.inc:678 #5 0x000000010036431a in swift::driver::PerformJobsState::runTaskQueueToCompletion() at /Users/omochi/work/swift-source/swift/lib/Driver/Compilation.cpp:1089 #6 0x0000000100361333 in swift::driver::Compilation::performJobsImpl(bool&, std::__1::unique_ptr<swift::sys::TaskQueue, std::__1::default_delete<swift::sys::TaskQueue> >&&) at /Users/omochi/work/swift-source/swift/lib/Driver/Compilation.cpp:1388 #7 0x00000001003675ec in swift::driver::Compilation::performJobs(std::__1::unique_ptr<swift::sys::TaskQueue, std::__1::default_delete<swift::sys::TaskQueue> >&&) at /Users/omochi/work/swift-source/swift/lib/Driver/Compilation.cpp:1501 #8 0x0000000100334d61 in run_driver(llvm::StringRef, llvm::ArrayRef<char const*>) at /Users/omochi/work/swift-source/swift/tools/driver/driver.cpp:176 #9 0x0000000100332632 in main at /Users/omochi/work/swift-source/swift/tools/driver/driver.cpp:246

2:55 PM

 // Spawn the subtask. int spawnErr = posix_spawn(&Pid, ExecPath, &FileActions, nullptr, const_cast<char **>(argvp), const_cast<char **>(envp));

2:55 PM

スタックトレースは↑で、この行に到達する。

2:56 PM

int Compilation::performJobs(std::unique_ptr<TaskQueue> &&TQ) { において、冒頭のperformSingleCommandに突入するif文をすり抜けるのが

2:56 PM

決定的な分岐かな。

ああ、frontend を spawn するですね。

この場合の外側はfrontendとは言わないんですね。よくわかってない。

-driver-print-jobs (うろ覚え)で実際にどんなコマンドが実行されているか調べて、直接実行してみるのがいいと思います。

おお　それは良さそう　ありがとうございます

swift -frontend がフロントエンド

りんたろーさんの記事にも書いてあった気がしてきた (edited)

swiftc はドライバーです。

なるほど。

3:01 PM

driver-print-jobsありました

3:02 PM

おお、でた

3:02 PM

あ〜〜〜

3:03 PM

/Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/bin/swift -frontend -c -filelist /var/folders/1v/_s33fkpj07g9y3zvdfs9cz9m0000gn/T/sources-ffe05d -supplementary-output-file-map /var/folders/1v/_s33fkpj07g9y3zvdfs9cz9m0000gn/T/supplementaryOutputs-7c1c06 -disable-objc-attr-requires-foundation-module -target x86_64-apple-macosx10.9 -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -I /Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift/macosx/x86_64 -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/../../../Developer/Library/Frameworks -warn-swift3-objc-inference-complete -warn-implicit-overrides -g -module-cache-path /Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/./module-cache -module-link-name swiftCore -nostdimport -parse-stdlib -resource-dir /Users/omochi/work/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/./lib/swift -swift-version 5 -Onone -D INTERNAL_CHECKS_ENABLED -D SWIFT_ENABLE_RUNTIME_FUNCTION_COUNTERS -enable-resilience -group-info-path /Users/omochi/work/swift-source/swift/stdlib/public/core/GroupInfo.json -verify-syntax-tree -enable-sil-ownership -Xllvm -sil-inline-generics -Xllvm -sil-partial-specialization -Xcc -DswiftCore_EXPORTS -Xcc -D__SWIFT_CURRENT_DYLIB=swiftCore -parse-as-library -module-name Swift -o Swift.o

3:03 PM

パラメータがテンポラリファイル経由になるんですが、これが消されてしまう

3:04 PM

なんか消さないためのif文があるな

3:04 PM

options::OPT_save_temps

3:04 PM

できた！

3:05 PM

ありがとうございます、これは捗る

それか、Xcode のデバッグで swift プロセス実行されるので待ち状態にしておけば、うまくアタッチ出来ないかな？

ドライバーにアタッチしちゃいます

なるほど。

debugのswiftでstdlibをコンパイルするとき、imacproで6分ぐらいかかるんだけど、semaが70%ぐらいの時間を消費していて、全然並列化もしていないんだけど

12:44 AM

型推論の並列化ってできないのかな直感的にはかなり難しそう

やばそう

あ、でも、メソッドに閉じてるからいけるのか？

型は全部生成された後で、メソッド毎にやるのはいけるんじゃないかな？と言う気がしてる、ただ、、

12:50 AM

変数を右辺から推論する系があってこいつが閉じない、難しそう

メソッドごとに並列化するだけで

12:51 AM

36並列は軽く使い切るから

12:51 AM

そこは良さそう

lazy var foo = mySignal.map {...}.flatMap{...} ↑こういう悪い子がいるとな

型の定義を洗い出すところはどのくらいかかってるのかねー

12:53 AM

たとえばそういう式が２つあれば、マシンパワーとしてはそれぞれで使い切るから問題ないよ

いや、コイツが存在すると型が非決定性にならないか?という話

12:54 AM

推論終わらないと型が決定しない

ジェネリックな型が複数箇所からアドホックに誕生する部分は

12:55 AM

推論自体がメソッド単位で並列化しても

12:56 AM

同期制御が必要だね

12:56 AM

推論自体は並列でも、型環境(？)はグローバルに合併していく

12:57 AM

stdlibのIRを得たいんだけど

12:58 AM

一手に6分かかるからしんどい

12:58 AM

同時に130ファイルぐらい突っ込まれる

https://github.com/apple/swift/pull/19388

change mangling prefix from $S to $s by eeckstein · Pull Request ...

This is the final ABI mangling prefix rdar://problem/38471478

3:49 AM

Swiftシンボルprefixが $S から $s に！

おお < "This is the final ABI mangling prefix"

3:59 AM

一瞬マングリングが定まったのかと思ったけどプレフィックスだけか。 (edited)

int swift::Demangle::getManglingPrefixLength(llvm::StringRef mangledName) { if (mangledName.empty()) return 0; llvm::StringRef prefixes[] = { /*Swift 4*/ "_T0", /*Swift 4.x*/ "$S", "_$S", /*Swift 5+*/ "$s", "_$s"}; // Look for any of the known prefixes for (auto prefix : prefixes) { if (mangledName.startswith(prefix)) return prefix.size(); } return 0; }

4:02 AM

bool swift::Demangle::isOldFunctionTypeMangling(llvm::StringRef mangledName) { return mangledName.startswith("_T"); }

4:03 AM

_T, _T0, $S, $s の 4つがこれまでにあるっぽい

4:04 AM

Swift5ではABIを安定化するから $s から代わる事は今後無いと・・・

4:05 AM

このPRで #define MANGLING_PREFIX $s になるってことは

4:05 AM

4.2リリースして、次はいよいよSwift5を目指すのか。

次は Swift 5 で 2019 年前半って公式にアナウンスされてる情報じゃないんだっけ？

4:13 AM

噂？

swift-evolution の README には Early 2019 とありますね。

おお

< swift-evolution の README には Early 2019 とありますね。

とはいえ、一回書き換え実績ありですけど

https://github.com/apple/swift-evolution/commit/de7727f7dcf7bbfdea6763a87f4c8c534f27406e

Update README.md · apple/swift-evolution@de7727f

Adjust expected release timeline for Swift 5.

お、なんか昔は次の冬にリリース予定だった気がしてたんですが、これを見た記憶かもしれないですね。

WWDCのセッション終わった瞬間に書き換えられてて、はや！ってなった記憶が

2

https://twitter.com/omochimetaru/status/1043455899245801474

おもちメタル (@omochimetaru)

投稿しました > SwiftコンパイラのManglingの勉強方法 https://t.co/8bQ9CZ6r80

4

11:04 AM

↑参考にしてくださいな

ほう @swift-4.2.4 demangle -expand $S1a3CatC4nameSSvg

Demangling for $S1a3CatC4nameSSvg kind=Global kind=Getter kind=Variable kind=Class kind=Module, text="a" kind=Identifier, text="Cat" kind=Identifier, text="name" kind=Type kind=Structure kind=Module, text="Swift" kind=Identifier, text="String" $S1a3CatC4nameSSvg ---> a.Cat.name.getter : Swift.String

lldb上でisとかisaって使えますか？

とある記事に載ってたコードですけど、 @swift-4.2.4

protocol SomeProtocol{ // required method func r() // optional method func o() } extension SomeProtocol { // optional methods func o() { print("o() in SomeProtocol") } func p() { print("p() in SomeProtocol") } } class SomeClass: SomeProtocol { func r() { print("r() in SomeClass") } func o() { print("o() in SomeClass") } func p() { print("p() in SomeClass") } } let sc: SomeClass = SomeClass() sc.r() // 出力 "r() in SomeClass" sc.o() // 出力 "o() in SomeClass" sc.p() // 出力 "p() in SomeClass" let sp: SomeProtocol = sc sp.r() // 出力 "r() in SomeClass" sp.o() // 出力 "o() in SomeClass" sp.p() // 出力 "p() in SomeProtocol"

r() in SomeClass o() in SomeClass p() in SomeClass r() in SomeClass o() in SomeClass p() in SomeProtocol

SomeProtocol が明示的に書かれている場合は、protocolの実装が優先されるのはともかく、なんでこうなるんだっけというのがコンパイラレベルで気になったのでだれか教えて〜

そうですね

7:10 AM

https://qiita.com/omochimetaru/items/7aa8f4582f357293782e

Swiftで継承とプロトコルとprotocol extensionが絡んだ...

Swiftで継承とプロトコルとprotocol extensionが絡んだ時に呼び出されるメソッドがわかりづらい事があるのでまとめました。

バージョン

``` $ swift --version Apple Swift v...

7:11 AM

↑ここに書いてるけど、その例の方がシンプルだ

7:11 AM

func r() と func o() は、プロトコル定義にエントリがあるから

7:11 AM

プロトコルとして呼び出したときにwitness tableを参照する

7:12 AM

func p() はプロトコル定義にエントリがないから

7:12 AM

witness tableにもエントリがないので

7:12 AM

静的ディスパッチになる。

めちゃシンプルに理解できた

let sc: SomeClass = SomeClass() sc.r() // 出力 "r() in SomeClass" ただのSomeClassのメソッド呼び出し sc.o() // 出力 "o() in SomeClass"　 ただのSomeClassのメソッド呼び出し sc.p() // 出力 "p() in SomeClass"　 ただのSomeClassのメソッド呼び出し let sp: SomeProtocol = sc sp.r() // 出力 "r() in SomeClass" 動的、SomeClass.rがテーブルから出てくる sp.o() // 出力 "o() in SomeClass"　動的、SomeClass.oがテーブルから出てくる sp.p() // 出力 "p() in SomeProtocol"　静的、式がSomeProtocolなのでSomeProtocol.pになる

(edited)

完全に理解した。ありがとう！

1

@d_date ↓もっとヤバいパターンです

@swift-main

protocol P { func a() -> String func b() -> String } extension P { func a() -> String { return "P" } func b() -> String { return "P" } } class C: P { func a() -> String { return "C" } } class SC: C { override func a() -> String { return "SC" } func b() -> String { return "SC" } } let sc: SC = SC() print(sc.a()) // SC print(sc.b()) // SC let c: C = sc print(c.a()) // SC print(c.b()) // P

SC SC SC P

c.b() はwitness tableを見にいくけどb()がcから取り出せず、静的DispatchでP.bになる。（あってます？） c.a() は実体はSCのインスタンスなので、SCのvTableを見にいって、SC.a()になる（あってます？） (edited)

ちょっと自信ないですが、僕の理解が正しければ、 b は SC の VTable にはあるけど C の VTable にはなくて、 C として呼ばれたときには SC の b とは同名同型の別の関数として静的ディスパッチされる、だと思います。

2

llvmの話題ってここでよい？

2:09 AM

/usr/local/Cellar/llvm/HEAD-3898e47/include/c++/v1/stdlib.h:94:15: fatal error: 'stdlib.h' file not found #include_next <stdlib.h>

llvmのチュートリアルのコンパイルができない・・・・前はできたのに・・・・． brewでllvmインストールして，コンパイルしてたのだが・・・・・

2:10 AM

https://llvm.org/docs/tutorial/LangImpl02.html # Compile clang++ -g -O3 toy.cpp `llvm-config --cxxflags` # Run ./a.out これをやると，stdlib.hが見つからないって言われて，あるのに・・・・って格闘中・・・・． LLVMチュートリアルのソースコードのコンパイルはこうすればいいよーってのがあったら教えてください・・・・・．ちょっと前までできてたのに・・・・・． (edited)

Mojave?

Mojaveです

なんとか動かせました

4:47 AM

でも，なんだか納得が行かない感じです．

4:50 AM

clang++だけ，/usr/bin/clang++を使うようにしたら動きました．どうやら，brewのclang++のサーチパスがおかしくなっているようです・・・・・．うーむ・・・・・

brew link あたりで修復してみるとか。

なるほど

ダメでした

5:59 AM

うーん

/use/includeはある？Command Line Toolsを入れてもMojave標準だと存在しません。

6:12 AM

以前の様に/use/includeが存在するのが前提で作られてるモノのために、別途インストールできる様になっています。

リリースノートのこの辺りに記述がある。 https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035623

1

ああああああああああああああああああああ

7:04 AM

@norio_nomura 神さま，野村さまそれでした・・・・・・・ (edited)

7:06 AM

ありがとうございました・・・・・

Xcode10.1, swiftc 11-01 snapshot で、 Xcodeでswiftターゲットをwait for executableしてからターミナルでswiftc実行しても、

Message from debugger: unable to attach

となってしまってデバッグができない・・・

1

4:30 PM

mojaveなのも関係あるかな

4:36 PM

Xcodeからの実行ならできるから、-driver-print-jobsしてから引数を指定すれば一応できるんだけど

4:37 PM

XcodeのEdit Schemeのところで10個とかのargv指定するのUI的に厳しいものがある・・

@omochimetaru high sierra 10.13.6 Xcode10.1で DEVELOPMENT-SNAPSHOT-2018-11-01-a のデバッガアタッチできました

マジか　違うのはHighSierraなところか・・・

DebugメニューのAttach to Process by PID or Name...でProcess Nameにswiftcを指定してAttachしてから、TOOLCHAINS=org.swift.4220181113a swiftcで起動したらアタッチできました。

3:52 AM

on Mojave

おお。帰宅したらやってみます

xcrun --toolchain org.swift.4220181113a swiftcだとデバッガが見つけてくれなかった。

WASM 始まった？ https://github.com/apple/swift/pulls?utf8=✓&q=is%3Apr+is%3Aopen+author%3Addunbar+WASM

1

おお？ddunbarさんはAppleの人なのか

ですね。とはいえ現在サンクスギビングなので個人的にやってる可能性はあります。

https://github.com/MaxDesiatov/swift/commits/swift-to-wasm-next

MaxDesiatov/swift

The Swift Programming Language. Contribute to MaxDesiatov/swift development by creating an account on GitHub.

2:03 AM

emscriptenのスレで成果報告してるこの人のとは全く別軸でやってそう

2:04 AM

ああ、今お休みなのか。

2:05 AM

あ、swift-clangの方にもPRが出てる。

デバッガがアタッチできない問題、Xcodeとhomebrewで入れてるもの全部消して再インストールしたけど治らなかった・・・

自分でビルドしたswiftc?

そうです、 util/build-script --debug --xcode --skip-build-benchmarks でビルドしたswift, swiftc

/Library/Developer/Toolchains/にインストールしたツールチェインのswiftcでもアタッチ出来るから、自前ビルドでも何か手順がありそうだけど… (edited)

でも、Launch = Automaticallyで起動するときはちゃんとアタッチできてデバッグもできるんですよ。

2:18 AM

あくまでLaunch = Wait for executable to be launchedができない。

ぬ。

Xcodeの、Edit SchemeのRunのページにあるやつです。

なるほど。

だから、プロセスが起動したのが、Xcodeからだったのか、別のターミナルからだったのかという違いによる、セキュリティ的な？何か？による副作用じゃないかと思ってます。Mojaveにしてから、というのもそれっぽい。

2:20 AM

でもこれ以上手を進めるアプローチがさっぱりわからず。

Debug process as rootをオンにしたら、Wait for executable to be launchedでTOOLCHAINS=org.swift.42120181030a xcrun swift使って起動したswiftにアタッチ出来た。

あ〜

repl_swiftにアタッチ出来たぽい。

2:28 AM

/Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swiftで起動してもアタッチ出来るから、自分でビルドしたものもいけそう。

Lost connection to "My Mac". Restore the connection to “My Mac” and run “swift” again, or if “swift” is still running, you can attach to it by selecting Debug > Attach to Process > swift.

2:28 AM

rootにしてみたら↑なぞのダイアログが

一度、自分のアカウントのパスワード入力が必要。

そうですね、初回はダイアログがでて、lldb-rpc-serverが権限を求めてきた

2:29 AM

そこは入力しました

2:30 AM

https://stackoverflow.com/questions/32412555/xcode-wait-for-os-x-app-to-launch-error-lost-connection-to-my-mac?rq=1

Xcode wait for OS X app to launch error: Lost connection to My Mac

I'm trying to debug a Terminal app upon launch, so I've created a new scheme and selected: I build my app, then I go to Terminal and run the app. Immediately, instead of hitting a breakpoint, I g...

管理者権限があるアカウントなら、それでイケるかと。

2:32 AM

あ、ブレークポイントとか設定せずにアタッチしただけだから、また何か違う状況かも。

replに対してAttach to Processだと確かにアタッチはできました

2:32 AM

お、ブレークもできた

2:33 AM

replなら待っててくれるけど

2:33 AM

$ swift --version とかを、wait for executable... で引っ掛けるのができないです。

Driver::MainLoopにシンボリックブレークポイント置いてちゃんと止まりました。 (edited)

2:35 AM

mainにシンボリックブレークポイント置いて、/Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swift --versionで止まりました。

うむむ

getSwiftFullVersionにシンボリックブレークポイントもいけました。

ブレーク以前にアタッチが反応しないんですよね

2:38 AM

debug as me のときは

2:38 AM

即座に「unabled to attach」と出てくるので、

2:39 AM

反応はしてて、失敗する

2:39 AM

rootのときは、反応しない

Executableはswiftにしてる。

同じです。Build Productの中のやつが選べるので、選んでて。

2:41 AM

ToolChainとしてインストールしてるかどうかの違いかな

xcschemeファイルを見ると/Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swiftと記述されてる。

2:42 AM

ソースからビルドは、当分は試せないかな。

あーこれ名前じゃなくてフルパスが裏にあるのか

2:45 AM

 <BuildableProductRunnable runnableDebuggingMode = "0"> <BuildableReference BuildableIdentifier = "primary" BlueprintIdentifier = "C6F405DB688E4209BE9944BB" BuildableName = "swift" BlueprintName = "swift" ReferencedContainer = "container:../build/Xcode-DebugAssert/swift-macosx-x86_64/Swift.xcodeproj"> </BuildableReference> </BuildableProductRunnable>

2:45 AM

プロジェクト + 名前みたいな指定になってました

2:49 AM

 <PathRunnable runnableDebuggingMode = "0" FilePath = "/Users/omochi/work/swift-source/build/Xcode-DebugAssert/swift-macosx-x86_64/Debug/bin/swift"> </PathRunnable>

直指定したらこうなったけど駄目でした、反応無し・・・

そちらで/Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swiftにアタッチ出来るかどうかで、ツールチェインとしてインストールしているかどうかの違いが原因か判るはず。

確かに。やってみます。

これにはアタッチできました > /Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swift

4:22 PM

デバッグビルドになってないからか、ソースビューは出なくてアセンブリだったのと、ブレークポイントは効かなかったけど。

4:22 PM

ついでにToolChainとしてXcodeがSwift4.2RELEASEを使うようにした場合は、↓のエラーでwait forができなかった。 Could not attach to name : “swift” Problems with launching via XPC. XPC error : Connection invalid

4:23 PM

デバッグするためにXcode DebuggerとSwiftCompiler側のlldbの何かが揃ってないといけなくて、それがずれてるとかそういう現象か？

4:25 PM

おお、Swift4.2RELEASEのソースからビルドしたswiftcなら両方の方式でアタッチできる。ただしwait forの場合 run as rootは必要だ。

こちらはXcode 10.1でツールチェインにSwift 4.2.1 Release 2018-10-30 (a)を選択してても、問題なく/Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swiftにアタッチ出来る。Wait for…もDebug Process As rootすればアタッチ出来るのも変わらず。 (edited)

むむ。そこは状況が違うのか・・・

あとは試す時に使ったプロジェクトの内容の差かな？

これか。

新規Command Line Toolプロジェクトでこれ再現したけど、deployment targetとか変えると再現しなくなる。

それです！

今までのテストは、たまたま開いてたフレームワークのプロジェクトでRunアクションにswiftを設定して試してた。 (edited)

なるほど。

新規作成で再現したプロジェクトでも、deployment targetを適当に変更してリビルドした直後だと、アタッチ出来たりする。

4:04 AM

とりあえず、開いているプロジェクトの状態から影響を受けるというのは間違いなさそう。

なるほど・・・　utils/build-scriptが生成したxcode projからやってると問題が起きるということは

4:05 AM

cmakeが生成してるxcodeprojとxcode10.1の相性問題の可能性がありますね

4:06 AM

とりあえず野村さんの方でXPCのダイアログが出たってことは、僕の固有問題じゃ無さそうだけど

4:06 AM

appleのコンパイラ開発者はXcodeは全然使ってないんだろうか。

4:08 AM

後で僕の方でも、他のxcdeprojからアタッチするのをやってみます

ぬ、SchemeのRunアクションの種類によるのかも。

4:16 AM

Yamsのxcodeprojに含まれるschemeのRunアクションで試してたのだけど、Application DataやRouting App Coverage Fileとかの項目がoptionsタブに存在するから、macOS向けのRunアクションではないぽい。

4:17 AM

マルチプラットフォームターゲットだからか。

4:21 AM

Yamsのxcodeprojを使って、Yams schemeのRunアクションでExecutableをswiftにして試してみて欲しいかも。

ぬうう、Yams.xcodeprojの作り方をなぞってみても、Yams.xcodeprojの様にXPCエラーが全く出ない状態にならない…

ああ、分かった。

4:54 AM

プロジェクトを開いた直後に、Scheme > Runアクション > Argumentsタブ > Expand Variables Based On をNoneにしてデバッガを実行すると動く。 (edited)

ほほう

4:55 AM

余計な環境変数が注入されちしまってる？

このNoneは、プロジェクトを閉じて再度開くと、NoneからSchemeのターゲットに戻ってしまう。

ええw

Yams.xcodeprojは、ここに過去存在して今は存在しないターゲットが設定されたままになってるため、Noneに戻らない。

4:56 AM

マルチプラットフォームターゲットとか全然関係なかった。

最短手順 1. 新規Command Line Toolプロジェクト作成。 2. SchemeのRunアクションInfoタブ

Executableに/Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swift

Debug Process As: root

Launch: Wait for executable to be launched

3. SchemeのRunアクションArguments タブ

Expand Variables Base On: None

4. Breakpoint Navigator

Symbolic breakpoint: getSwiftFullVersion

5. ⌘R 6. ターミナルで /Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swift -version 実行

XPC errorを出す手順ですか？

XPC errorを出さずに/Library/Developer/Toolchains/swift-4.2.1-RELEASE.xctoolchain/usr/bin/swiftをアタッチする手順

ああ。XcodeのToolchainを4.2.1-RELEASEにした場合で、ですよね

そう。

帰宅後にやってみます！

xcodeprojを再度開いた時、Expand Variables Base On: Noneし忘れて一度XPC errorになったら、閉じるまではExpand Variables Base On: Noneしてもダメ。

5:14 AM

開き直して、Expand Variables Base On: Noneすれば大丈夫。

毎回Expand Variables Base On: Noneしなくても良くするには、 1. Libraryターゲットdummy追加 2. メインのschemeのBuildアクションにdummyを追加。 3. RunアクションのExpand Variables Base Onをdummyに。 4. dummyターゲット削除、Buildアクションにはdummy (missing)が残り、Expand Variables Base Onもdummy (missing)のままになり、プロジェクトを再度開いてもそのまま残る。

missingで残すのなるほどｗ

で、自前ビルドしたswiftにアタッチ出来ない問題も、このExpand Variables Base Onの影響を受けているのならば、missingで回避出来るかも？

ありえそうですね、Base On の対象はcmakeで生成されてるものだし、

5:28 AM

4.2.1ならいけて最近のmasterでは駄目っていうのも

5:28 AM

プロジェクト設定はリポジトリに依存してるから、そこで変化が起きるのも筋が通る

5:28 AM

もしその路線なら最終的にはExpand Variablesの副作用の根本原因を取り除くのが一番良さそう。

プロジェクトのswiftコマンドのターゲットから作ったschemeだと、Expand Variables Based Onのコントロールがグレーアウトしてて変更できないようです

12:16 PM

空のschemeを自作してからexecutablesを指定するのだと、変更できるので、それでmasterビルドで実験してみます

RunアクションのExecutableを変更しないと、Expand Variables Base Onは変更できないですね。

ああ、本当だ。

12:44 PM

うーんこのexpand variables baesd onって

12:44 PM

単純に他のschemeの、argumentsとenvvarsをコピーしてくるって機能なんですかね

12:44 PM

なんでそれがXPCエラーに絡むんだ・・・

あれ・・・・・？？？

1:10 PM

できました

Arguments Passed on LaunchやEnvironment Variables内で${SRCROOT}などを使う時に、元となる設定をどのターゲットから持ってくるか、を設定するものかと。

Xcode10.1 , Toolchain Xcode10.1 標準, swift source 直近のmaster, で、 Debug Process as root で、

1:11 PM

Wait for exceutable to launched が動きました

おめ

多大なサポートありがとうございました

1

1:14 PM

結局、なにか変わった点は、 Debug Process as root だけでしたでもこれも前試したはずだから、ソース側でも何かが変わって治ったのかも

Visual Studio CodeでLLVM tutorialのC/C++のコードをデバッグしようとしたら，

Stopping due to fatal error: DllNotFoundException: libc.dylibStopping due to fatal error: DllNotFoundException: libc.dylib

が出て，プロセスにアタッチできない・・・・．誰か，同じような現象にあったことがある方いらっしゃいませんか？

この人と同じエラー出てmasterをビルド出来ないんですが、他にも同じエラー出た人居ますか？再現方法は、 1. utils/update-checkout --scheme master 2. sudo xcode-select -s /Applications/Xcode-beta.app/Contents/Developer -> Xcode 10.2 beta 3 3. utils/build-script -x -rt --debug-swift -c https://forums.swift.org/t/swift-build-script-failed-clang-error-no-such-file-or-directory-we4062/21127 (edited)

Swift Build-Script Failed: clang: error: no such file or directory...

I am trying to build the Swift source for development, following the instructions in the README for macOS. I am running the build script with the --debug-swift, --xcode, and --clean options: utils/build-script --release-debuginfo --debug-swift --xcode -clean The build ends...

Ninjaビルドだけなら通るな。XcodeビルドでClangのヘッダーインポートに失敗している気がする

@rintaro text がinternalじゃなくてpublicだと嬉しいんですが、なにか困ることありますか？ https://github.com/apple/swift-syntax/blob/master/Sources/SwiftSyntax/TokenKind.swift.gyb#L35

apple/swift-syntax

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

@kitasuke 安全方向に振って必要な物だけ出してるだけだと思うので、ユースケース示して要望出してみるといいと思います。

書いてみます！今回のユースケースは、StringLiteralExprSyntaxの値が空文字かどうか判定するのに下記のコード書く時にstringQuoteやmultilineStringQuoteのtext使いたかったです。まあ無くても別に問題ないのであったら良いなぐらいですね。

 public override func visit(_ node: StringLiteralExprSyntax) { let value = node.stringLiteral.text guard value != "\"\"", value != "\"\"\"\"\"\"" else { return } ... }

(edited)

@rintaro SwiftSyntaxのリリースタグ付いてるやつは、gyb_generated以下のファイルだけ最新になっててそれ以外のSources/SwiftSyntax以下のファイルは相当古いままのやつが使われてるんですが、それって期待通りなんですか？下記のコミットが0.50000.0 タグ相当の状態です。 https://github.com/apple/swift-syntax/tree/43aa4a19b8105a803d8149ad2a86aa53a77efef3/Sources/SwiftSyntax

apple/swift-syntax

SwiftPM package for SwiftSyntax library. Contribute to apple/swift-syntax development by creating an account on GitHub.

@kitasuke 返事おそくなりましたー。SwiftSyntax の 5.0 ブランチは、11/16 のリブランチ以来ほとんど変更はなく、gyb は SwiftPM での dependency として使えるようにするために swift 5.0 ブランチから生成したものなので、そこだけ新しいファイルになっています。

12:43 AM

SwiftSyntax master ブランチはAPI変更を含むかなりの変更が入っていますが、それらは 5.0 には反映されません。

そうなのかー。そしたらKuniwakさんの Syntax.swift に関する変更は入らないのか... https://github.com/apple/swift-syntax/pull/94/files

Pretty results of dump() for Syntax by Kuniwak · Pull Request #94...

The result of dump() with Syntax is not useful. For example, the dumped result of Tests/SwiftSyntaxTest/Inputs/closure.swift is the following: ▿ // A closure without a signature. The test will ensu...

ですね。swift-5.1-branch のリリースには含まれることになると思います。

2

ちなみに、おもちさんに #swift-syntax チャネル作ってもらいました。そこに投稿したイシューについてrintaroさんの意見も聞いてみたいです！

LLVM_DEBUGのメッセージって、ファイルの先頭に #define DEBUG_TYPE "sil-inliner" ってタグの定義がついてて

1:44 AM

コンパイラ実行時に $ swiftc -emit-sil -Xllvm -debug-only=sil-inliner ってやると

1:44 AM

それだけ見れるんだね

1:44 AM

http://llvm.org/docs/ProgrammersManual.html#fine-grained-debug-info-with-debug-type-and-the-debug-only-option

-Xllvm -sil-disable-passでMandatory系を消してやるとSILがわかりやすくなるな。

1

.swiftmoduleと.swiftdocの中身を見たりダンプするコマンドってありますか？

llvm のビルドディレクトリ/binにある llvm-bcanalyzer -dump で llvm ビットコード全般ダンプできるんですが、Swift向けに作られているわけでは無く、独自のコンテナの中身は見られないので、あまり参考にはならないです。 (edited)

なるほど、ありがとうございますその場合、コンテナの中身のコンテンツはただのバイナリとしてしか見えないってことですよね

12:15 AM

swiftcの動作モードとかで隠し的なのがあるかなあと

例として、Swift.swiftdoc はこんな感じ。

<BLOCKINFO_BLOCK/> <MODULE_DOC_BLOCK NumWords=813176 BlockCodeSize=2> <CONTROL_BLOCK NumWords=32 BlockCodeSize=3> <METADATA abbrevid=5 op0=1 op1=1 op2=0 op3=0/> blob data = 'Swift version 5.0-dev (LLVM 06f1615069, Swift edb924f743)' <MODULE_NAME abbrevid=4/> blob data = 'Swift' <TARGET abbrevid=6/> blob data = 'x86_64-apple-macosx10.9' </CONTROL_BLOCK> <COMMENT_BLOCK NumWords=813139 BlockCodeSize=4> <DECL_COMMENTS abbrevid=4 op0=3181980/> blob data = unprintable, 3247524 bytes. <GROUP_NAMES abbrevid=5/> blob data = unprintable, 5004 bytes. </COMMENT_BLOCK> </MODULE_DOC_BLOCK>

12:16 AM

swiftcの動作モードとかで隠し的

残念ながら、知ってる限り無いです。

アスキーで読めるところは読めるんですね。

12:16 AM

なるほど。無いならツールを作ってみようかな

いいっすね。 llvm-bcanalyzer ベースにするのもアリだとおもいます。

コンテナへのアクセスにコマンドを叩くって意味ですか？

Carthageで、frameworkがビルドされたSwiftのバージョン判定するのに-Swift.hを見てて、代わりにswiftmoduleからバージョン知れたらいいなと思っていたけど、骨折れるなと思って見送っていたので、そういうツール・ライブラリあるとめっちゃ喜びます

(edited)

なるほど、そんな利用方法がw

Swift 5.1？でModule Stabilityが実現されたらSwiftバージョン判定（バージョン違いでキャッシュを無効にするため）必要なくなりそうではあるんですけど。 (edited)

コンパイラツールチェインが勝手に判断するようになる？

例えばSwift 5.1でビルドしたものをSwift 5.2のコンパイラでもインポートできるようになるので、ビルドしたバージョンと、今ローカルで使っているバージョンが違ってもキャッシュを無効と判断する必要がなくなる、って感じですね。Module Stability以前と以後が入り混じるタイミングだとやっぱり判定してあげる必要ありそうですけど。

Carthageの用途だと5.2でリビルドしたほうが良い気はします最適化とか進化してるかもしれないし

キャッシュが使われるのは--cache-buildをつけた時だけじゃないかな

なるほど、それでも警告でリビルド促すくらいにはしたいですね

12:56 AM

はい、--cache-buildsの時の話です

あ、なるほど、デフォルトは関係ないのか警告はいいですね

--cache-buildsを付けたときはキャッシュを使う、が良いと思います。警告はありですが、だいたい誤解されて伝わるのでなくていいんじゃないかな

誤解w

Prebuiltバイナリを提供してたとき、互換性がないから再ビルドするメッセージを何かのエラーだと思う人が結構な数いて、Issueが定期的に来ていました。 (edited)

あぁ〜〜意味がよくわかんないけど黄色いから、問題ないんですか！？ってなるやつ・・

ローカルでのビルドにフォールバックしてて問題ないのに、ってやつですね (edited)

そうそう。まあ、知らないとわからないやつだから、気持ちはわかる。

1:01 AM

バージョンが上がるたびにビルドできなくなるSwiftも悪い

https://github.com/realm/realm-cocoa/issues/6134 ちょうどRealmSwiftにそういうIssueが来てた

自分のはもうPrebuiltバイナリ置かなくしたけど、置いてるのは定期的にこういうIssueが来る。

Carthage: "Incompatible Swift version - framework was built with 5...

!!! MANDATORY TO FILL OUT !!! Goals Install Realm using Carthage Expected Results Framework file to appear in Carthage->builds folders Actual Results I am getting the following error ***Inco...

なるほど・・・

BLOCKINFO#0 { } BLOCKINFO#0 MODULE_BLOCK#8 { CONTROL_BLOCK#9 { MODULE_NAME#2 METADATA#1 TARGET#3 OPTIONS_BLOCK#16 { IS_SIB#3 IS_TESTABLE#4 SDK_PATH#1 XCC#2 XCC#2 } OPTIONS_BLOCK#16 } CONTROL_BLOCK#9 ...

7:52 AM

LLVM BitStream のパースができた。

7:53 AM

バイナリJSONみたいなものなんだけど、データ構造を記述するセクションがあって、それに基づいてパースするのが面白い。

7:54 AM

swiftmoduleはこれの上にエンコードされてる

https://forums.swift.org/t/plan-for-module-stability/14551

Plan for module stability

As you can probably tell, I've been saving a lot of discussions, waiting for Swift 4.2 to be in a pretty good place before we jump all in on Swift 5. This one's one of the main things I plan to be working on in the next year or so, so I wanted to make sure you all had the big...

3:26 AM

swiftinterfaceができたらswiftmoduleを気にする必要はないんだろうか (edited)

3:26 AM

ラトナーが

This also leverages the existing "generated interface" work nicely, and forces it to be round-trippable, which is also great.

3:27 AM

ラウンドトリップにできたらいいね、と言ってるから、その場合は、どちらをみても完全に同じになる

https://forums.swift.org/t/update-on-module-stability-and-module-interface-files/23337

Update on Module Stability and Module Interface Files

Hi, everyone! It's about time we give an update on module stability. TLDR: it's looking good. Aside: who's "we"? These days, it's mostly me, @harlanhaskins, and @Nathan_Hawes, but I also want to acknowledge contributions from @Graydon_Hoare before he left the project. We'...

3:38 AM

ホヤホヤで試せるやつでてた

@swift-main

import Foundation let interface = try! String(contentsOfFile: "/usr/lib/swift/linux/x86_64/Swift.swiftinterface") print(interface)

// swift-interface-format-version: 1.0 // swift-tools-version: Swift version 5.0-dev (LLVM 06f1615069, Swift 844d4df31a) // swift-module-flags: -disable-objc-attr-requires-foundation-module -target x86_64-unknown-linux-gnu -disable-objc-interop -enable-library-evolution -module-link-name swiftCore -parse-stdlib -swift-version 5 -O -enforce-exclusivity=unchecked -module-name Swift import SwiftShims @inlinable public func min<T>(_ x: T, _ y: T) -> T where T : Swift.Comparable { // In case `x == y` we pick `x`. // This preserves any pre-existing order in case `T` has identity, // which is important for e.g. the stability of sorting algorithms. // `(min(x, y), max(x, y))` should return `(x, y)` in case `x == y`. return y < x ? y : x } @inlinable public func min<T>(_ x: T, _ y: T, _ z: T, _ rest: T...) -> T where T : Swift.Comparable { var minValue = min(min(x, y), z) // In case `value == minValue`, we pick `minValue`. See min(_:_:). for value in rest where value < minValue { minValue = value } return minValue } @inlinable public func max<T>(_ x: T, _ y: T) -> T where T : Swift.Comparable { // In case `x == y`, we pick `y`. See min(_:_:). return y >= x ? y : x } @inlinable public func max<T>(_ x: T, _ y: T, _ z: T, _ rest: T...) -> T where T : Swift.Comparable { var maxValue = max(max(x, y), z) // In case `value == maxValue`, we pick `value`. See min(_:_:). for value in rest where value >= maxValue { maxValue = value } return maxValue } @_fixed_layout public struct EnumeratedSequence<Base> where Base : Swift.Sequence { @usableFromInline internal var _base: Base @inlinable internal init(_base: Base) { self._base = _base } } extension EnumeratedSequence { @_fixed_layout public struct Iterator { @usableFromInline internal var _base: Base.Iterator @usableFromInline internal var _count: Int @inlinable internal init(_base: Base.Iterator) { self._base = _base self._count = 0 } }

stdout.txt

https://file.io/eTXB8p

おー

3:55 AM

インライン見えてる

3:59 AM

swiftmoduleにはSIB(バイナリのSIl)が入ってると思ってたけど swiftinterfaceはソースが入ってるのか

面白いね。

こっちを使うときはコンパイルしてSIL生成してからインライン化埋め込みするのかな

4:01 AM

swiftmoduleはseiftinterfaceのキャッシュになるって事だから

4:01 AM

おかしくはないけどデコンパイルはできないからラウンドトリップにはならないな (edited)

4:02 AM

このスレで聞いてみよ

5.1にも.swiftinterface入ってるのか。

@Yuta Saito １年前を思い出しながらSwiftPowerAssertから-dump-astのParserの部分を独立させて、現行の環境で動くようにしました。よかったら参考にしてください。 https://github.com/kishikawakatsumi/SwiftAST 使い方は swift-ast parse [FILE_PATH_TO_PARSE] -buildCommand [BUILD_COMMAND_TO_BUILD_THE_PROJECT] 例えば path/to/swift-ast parse "./Framework/Sources/SpreadsheetView.swift" -buildCommand xcodebuild -scheme SpreadsheetView や、

path/to/swift-ast parse ./Lib/KeychainAccess/Keychain.swift -buildCommand xcodebuild -scheme KeychainAccess -sdk iphonesimulator -destination "name=iPhone Xs,OS=12.2"

です。以下、思い出したことを書きます。 (edited)

kishikawakatsumi/SwiftAST

Experimental project for parsing an output that swift -dump-ast produces - kishikawakatsumi/SwiftAST

1

1:56 PM

-dump-astは全ての型が解決しているので原則としてコンパイルが成功する必要があります。簡単な（依存関係がない）ファイルなら簡単ですが、他のファイルやモジュールを参照している場合は同じモジュールのファイルの場合はそれを一緒に渡す、別モジュールの場合はそれを先にビルドする必要があります。なので、時間は余計にかかるのですが、 https://github.com/kishikawakatsumi/SwiftAST/blob/master/Sources/SwiftAST/XcodebuildTool.swift#L37-L42 のように swift -dump-ast を実行する前にまずビルドしています。ビルドエラーが起こる状態で swift -dump-ast を実行した場合、単に失敗するか不完全なASTが出力されます。 swift -dump-ast の出力自体が謎であるのにさらに不完全なASTを相手にするのは無理なので、最初のキモは確実にビルドできるパラメータを組み立てることです。 (edited)

kishikawakatsumi/SwiftAST

Experimental project for parsing an output that swift -dump-ast produces - kishikawakatsumi/SwiftAST

2:01 PM

最初のハードルを超えたら、完全なASTのテキストが手に入るので、それを読んでいくだけです。難しいのは constructor_decl や brace_stmt assign_expr といったノードの種類がよくわからないことと、それぞれがどういう属性を持っているかが当然Undocumentedでよくわからないところで、Parse自体はそれほど難しくないはず（目的にもよりますが）です。

2:05 PM

https://github.com/kishikawakatsumi/SwiftAST/blob/master/Sources/SwiftASTCore/SwiftAST.swift#L39-L46 ^ を見ると私がどのようにやったかがわかります。

private func process(sourceFile: URL, verbose: Bool = false) throws -> AST { let arguments = buildArguments(source: sourceFile) let rawAST = try dumpAST(arguments: arguments) let tokens = tokenize(rawAST: rawAST) let node = lex(tokens: tokens) let root = parse(node: node) return root }

dumpAST(arguments:)はswift -dump-astを実行します。得られたテキストをtokenize(rawAST:)でトークンに分割して、lex(tokens:)でツリー構造を作ります。最後にparse(node:) でツリー構造のデータに意味を持たせます。

kishikawakatsumi/SwiftAST

Experimental project for parsing an output that swift -dump-ast produces - kishikawakatsumi/SwiftAST

2:09 PM

-dump-astの出力はS式のように見えるのでカッコを頼りにしたくなりますが、別の意味のカッコが普通に（"や'に囲まれることなく）出てくるのでそれは難しいです。代わりに行とインデントを使います。

2:12 PM

func tokenize(source: String) -> [ASTToken] { var lines = [String]() for line in source.split(separator: "\n", omittingEmptySubsequences: false) { let trimmed = line.trimmingCharacters(in: .whitespaces) if trimmed.hasPrefix("(inherited_conformance") || trimmed.hasPrefix("(normal_conformance") || trimmed.hasPrefix("(abstract_conformance") || trimmed.hasPrefix("(specialized_conformance") || trimmed.hasPrefix("(assoc_type") || trimmed.hasPrefix("(value req") || !trimmed.hasPrefix("(") { continue } lines.append(String(line)) } ...

-dump-astの出力をまず行ごとに分割します。このとき、いくつかのプロジェクトでノイズになる行（実行コードには関係なく見える上にインデントがおかしい）が発見されたのでそれを取り除いています。

2:17 PM

そのあと、１行ごとに１文字ずつIterateしながらトークンに分割していきます。私の場合はindent（先頭の空白）、symbol（シングルクオートで囲まれた文字列）、string（ダブルクオートで囲まれた文字列）、token（それ以外の文字列や記号）に分類しました。 class ASTToken { enum TokenType { case token case symbol case string case indent(Int) }

この段階でテキストがトークンに分割されたものが手に入ります。

▿ 1498 elements ▿ 0 : ( ▿ 1 : source_file ▿ 2 : "/Users/katsumi/Documents/XcodeProjects/SwiftPowerAssert/Fixtures/Atlas/Sources/Atlas/Atlas.swift" ▿ 3 : __ ▿ 4 : ( ▿ 5 : struct_decl ▿ 6 : range ▿ 7 : = ▿ 8 : /Users/katsumi/Documents/XcodeProjects/SwiftPowerAssert/Fixtures/Atlas/Sources/Atlas/Atlas.swift:1:8 - line:17:1 ▿ 9 : "Country" ▿ 10 : interface ▿ 11 : type ▿ 12 : = ▿ 13 : 'Country.Type' ...

2:26 PM

ASTLexer がこのトークンの配列をツリー構造にします。Lexerといってますが、ツリー構造に変換するだけです。

2:29 PM

[(, source_file, "/Users/katsumi/Documents/XcodeProjects/SwiftPowerAssert/Fixtures/Atlas/Sources/Atlas/Atlas.swift"] [(, struct_decl, range, =, /Users/katsumi/Documents/XcodeProjects/SwiftPowerAssert/Fixtures/Atlas/Sources/Atlas/Atlas.swift:1:8 - line:17:1, "Country", interface, type, =, 'Country.Type', access, =, public, non-resilient] [(, pattern_binding_decl, range, =, /Users/katsumi/Documents/XcodeProjects/SwiftPowerAssert/Fixtures/Atlas/Sources/Atlas/Atlas.swift:2:12 - line:2:22] [(, pattern_typed, type, =, 'String'] [(, pattern_named, type, =, 'String', 'code', )] [(, type_ident] [(, component, id, =, 'String', bind, =, Swift.(file).String))))] [(, var_decl, range, =, /Users/katsumi/Documents/XcodeProjects/SwiftPowerAssert/Fixtures/Atlas/Sources/Atlas/Atlas.swift:2:16 - line:2:16, "code", type, =, 'String', interface, type, =, 'String', access, =, public, let, readImpl, =, stored, immutable] [(, accessor_decl, implicit, range, =, /Users/katsumi/Documents/XcodeProjects/SwiftPowerAssert/Fixtures/Atlas/Sources/Atlas/Atlas.swift:2:16 - line:2:16, 'anonname=0x10a8205a8', interface, type, =, '(Country) -> () -> String', access, =, public, get_for, =, code] [(, parameter, "self", interface, type, =, 'Country', )] [(, parameter_list, )] [(, brace_stmt, implicit, range, =, /Users/katsumi/Documents/XcodeProjects/SwiftPowerAssert/Fixtures/Atlas/Sources/Atlas/Atlas.swift:2:16 - line:2:16] [(, return_stmt, implicit] ...

こんな感じです。これでツリー構造とノードの種別や属性情報がプログラムから扱える形になりました。

2:36 PM

ここまではそんなに難しくなくて、大変なのはソースコードから生成されるASTが難しいので、この情報を使っていくところです。わかりやすいところでstruct_declとかvar_decl、call_expr、member_ref_expr、dot_syntax_call_exprなどです。それ以外に膨大な種類のノードがあるので、全部に対応するのはとても大変なので、必要に応じてノードをフィルタして使っていく、というのが良いかと私は考えています。

2:41 PM

その必要なところだけ使う、というのをやっているのがASTParserで、

private func parseSourceFileNode(node sourceFileNode: ASTNode<[ASTToken]>) -> AST { var declarations = [Declaration]() for node in sourceFileNode.children { for token in node.value { switch (token.type, token.value) { case (.token, "top_level_code_decl"): declarations.append(.topLevelCode(parseTopLevelCodeDeclarationNode(node: node))) case (.token, "import_decl"): declarations.append(.import(parseImportDeclarationNode(node: node))) case (.token, "struct_decl"): declarations.append(.struct(parseStructDeclarationNode(node: node))) case (.token, "class_decl"): declarations.append(.class(parseClassDeclarationNode(node: node))) case (.token, "enum_decl"): declarations.append(.enum(parseEnumDeclarationNode(node: node))) case (.token, "extension_decl"): declarations.append(.extension(parseExtensionDeclarationNode(node: node))) case (.token, "func_decl"): declarations.append(.function(parseFunctionDeclarationNode(node: node))) default: break } } } return AST(declarations: declarations) }

のようにまずStructやClass宣言を拾って、そのあと例えば関数だったら

2:41 PM

private func parseFunctionDeclarationNode(node: ASTNode<[ASTToken]>) -> FunctionDeclaration { let tokens = node.value let name = parseString(tokens: tokens) ?? parseSymbol(tokens: tokens) let accessLevel = parseAccessLevel(tokens: tokens) var parameters = [Parameter]() var body = [Statement]() for node in node.children { for token in node.value { switch (token.type, token.value) { case (.token, "parameter_list"): parameters.append(contentsOf: parseParameterListNode(node: node)) case (.token, "brace_stmt"): body.append(.expression(parseExpressionNode(node: node))) default: break } } } return FunctionDeclaration(accessLevel: accessLevel, name: name!, parameters: parameters, body: body) }

パラメータやステートメントをさらに拾っていく、としています。一番大変なのがこのParser部分を作っていくところだと思います。ここは自分が利用する情報を探しながらトライアルアンドエラーで書いていくことになります。

非常に丁寧な解説ありがとうございます！実はこの週末でPowerAssertをメチャクチャ参考にしながら、括弧ベースのパーサコンビネータからインデントベースの実装に書き換えて、なんとか動くところまで出来ました。

2:43 PM

https://github.com/kateinoigakukun/TouchTypist

kateinoigakukun/TouchTypist

Speed up your build time. Rewrite your source code as type annotated. - kateinoigakukun/TouchTypist

swift-astをいくつかのプロジェクトで試しましたが、clangモジュールのインポートをするためのパラメータが足りていない様です。 output: <unknown>:0: error: missing required module 'clibc' あと、-showBuildSettingsの出力は-jsonを使うとパースが簡単になると思います。 (edited)

1

parameter_listをインデントベースでパースすると正しくrangeを取れないので例外的に処理することにしたんですが、こういう例外が他にも結構ありそうで、なかなか道のりは長そうです。。。

(parameter_list (parameter "i" interface type='Int') range=[foo.swift:1:17 - line:1:17]) https://github.com/kateinoigakukun/TouchTypist/blob/master/Sources/TypeCheckedAST/Parser/CanonicalTransformer.swift#L22-L29 (edited)

kateinoigakukun/TouchTypist

Speed up your build time. Rewrite your source code as type annotated. - kateinoigakukun/TouchTypist

こういうやつですよね？

(constructor_decl range=[/Users/katsumi/Documents/XcodeProjects/KeychainAccess/Lib/KeychainAccess/Keychain.swift:229:12 - line:231:5] "init(rawValue:)" interface type='(AuthenticationPolicy.Type) -> (UInt) -> AuthenticationPolicy' access=public designated (parameter "self" interface type='AuthenticationPolicy' inout) (parameter_list (parameter "rawValue" apiName=rawValue interface type='UInt') range=[/Users/katsumi/Documents/XcodeProjects/KeychainAccess/Lib/KeychainAccess/Keychain.swift:229:16 - line:229:31])

問題なさそうに見えますけど、どういう風に違いますか？

2:56 PM

@norio_nomura xcodebuild -showBuildSettings -json -scheme KeychainAccess みたいに書けるんですね。。。

↓こうなっていれば綺麗にパースできるんですが、 (parameter_list range=[foo.swift:1:17 - line:1:17] (parameter "i" interface type='Int'))

2:58 PM

rangeがparameterの行に後置されてるので、改行ベースだとparameterの要素として扱われて都合が悪いんですよね。

(parameter_list (parameter "i" interface type='Int') range=[foo.swift:1:17 - line:1:17]) // ここまでparameterの要素としてパースされる

(edited)

ああなるほど。そうですねえ、そういう都合に合わないケースはありそうですね。

3:02 PM

ある程度動くようになったら、OSSプロジェクトに対してかけていくといろいろうまくいかないケースが見つかります。私はこういうの作って失敗するケースを見つけて調整して、、、の繰り返し https://github.com/kishikawakatsumi/SwiftPowerAssertIntegrationTests

kishikawakatsumi/SwiftPowerAssertIntegrationTests

Contribute to kishikawakatsumi/SwiftPowerAssertIntegrationTests development by creating an account on GitHub.

おお、、、やっぱりトライアンドエラーでやっていくしか無さそうですね。

3:08 PM

ここまで大変だとswiftcのコードにtype checkedなastをjsonで出力する機能を付けたほうが楽だったのでは。。。という気になってきました。。。

それはかなり理想的、、、私が一番やりたいのはAST to ASTですね。途中でJSONとかに落とすんじゃなくてビルドに割り込んでASTの形で受け取ってASTを変換して返す。

確かに。ビルドパイプラインに割り込めるようになると夢は広がりそうですね

TypeAnnotationを付けていく、のはおもしろいですね。逆はビルドできなくなる可能性があるけど、付けるぶんにはたぶん問題ないんですかね？ (edited)

正しい型情報が追加される分には、今のところ問題は起きてないですね

clangモジュールのインポートをするためのパラメータが足りていない

XcodebuildTool.constructSwiftOptions(xcodebuildLog:)で-fmodule-map-file=も使う必要がある。

Package.swiftから子ターゲットのPackage.swiftを読んでいって、modulemapを見つけたら追加、って感じかなあ？

xcodebuildLog中のswiftcへ渡されてるパラメータに含まれていますよ。 (edited)

あれ、 xcodebuildでビルドした場合もclibcないって言われます？

1:58 AM

swift buildの場合だけかと思っていました。でもありそうだな。。

SwiftASTでswift package generate-xcodeprojしてswift run swift-ast parse Sources/SwiftAST/main.swift -buildCommand xcodebuild -scheme SwiftASTで言われます。

2:05 AM

$ swift package generate-xcodeproj warning: invalid duplicate target dependency declaration 'swift-build' in target 'FunctionalPerformanceTests' warning: invalid duplicate target dependency declaration 'swift-package' in target 'FunctionalPerformanceTests' generated: ./SwiftAST.xcodeproj $ swift run swift-ast parse Sources/SwiftAST/main.swift -buildCommand xcodebuild -scheme SwiftAST warning: invalid duplicate target dependency declaration 'swift-build' in target 'FunctionalPerformanceTests' warning: invalid duplicate target dependency declaration 'swift-package' in target 'FunctionalPerformanceTests' Reading project settings... Building dependencies... Parsing... failed to run the following command: '/usr/bin/xcrun swift -frontend -suppress-warnings -dump-ast -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/../../../Developer/Library/Frameworks -target x86_64-apple-macosx10.10 -I /Users/norio/Library/Developer/Xcode/DerivedData/SwiftAST-gglvpwfxcdqcbehkwkywmelahzns/Build/Products/Debug -F /Users/norio/Library/Developer/Xcode/DerivedData/SwiftAST-gglvpwfxcdqcbehkwkywmelahzns/Build/Products/Debug -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks -primary-file /Users/norio/github/SwiftAST/Sources/SwiftAST/main.swift /Users/norio/github/SwiftAST/Sources/SwiftAST/Errors.swift /Users/norio/github/SwiftAST/Sources/SwiftAST/ParseTool.swift /Users/norio/github/SwiftAST/Sources/SwiftAST/SwiftASTTool.swift /Users/norio/github/SwiftAST/Sources/SwiftAST/SwiftBuildTool.swift /Users/norio/github/SwiftAST/Sources/SwiftAST/XcodebuildTool.swift' output: <unknown>:0: error: missing required module 'clibc'

1

2:11 AM

SourceKittenでもSourceKitへ渡すswiftcパラメータの構築をやっていて、

xcodebuildのログからswiftcへ渡されるパラメータを取得
XcodeのNew Build SystemがDerivedData内に作成するllbuildマニフェストから取得
SwiftPMのllbuildマニフェストdebug.ymlから取得

という3パターンをサポートしてます。 https://github.com/jpsim/SourceKitten/blob/master/Source/SourceKittenFramework/Module.swift (edited)

jpsim/SourceKitten

An adorable little framework and command line tool for interacting with SourceKit. - jpsim/SourceKitten

llbuildマニフェストから取得する方法は、クリーンビルドしなくても済むというメリットがあります。

クリーンビルドしなくても済むというメリット

これはいいですね。

New Build Systemのllbuildマニフェストから取り出すコード。Yams使って読んでるけど、今だとllbuildSwiftとか使えるのかな？ https://github.com/jpsim/SourceKitten/blob/67b93b83bafa83306fbb9dd201d4dfd22661a53a/Source/SourceKittenFramework/Xcode.swift#L287-L322

jpsim/SourceKitten

An adorable little framework and command line tool for interacting with SourceKit. - jpsim/SourceKitten

2:39 AM

SourceKittenはモジュール名を使って探すけど、SwiftASTはどうやって探すべきだろう？

ひさびさに update-checkout --cloneしたら、いろいろ増えてた

Cloning 'sourcekit-lsp' Cloning 'libcxx' Cloning 'indexstore-db' Cloning 'swift-stress-tester' Cloning 'swift-syntax' Cloning 'clang-tools-extra'

build-scriptがいつのまにか完全pythonになってる、bashと比べるとめっちゃ読みやすい、型が無いのでよくわからんが

1

完全にはなってなかった、pythonからbuild-script-implを個別のタスクごとに何度も呼び出す

Catalina beta 2 + Xcode 11 Beta 2 環境で master の --debug --xcode のビルド通らねえ・・・

6:41 PM

去年もWWDC直後からしばらく全然通せなかったんだよな〜・・・

WWDC直前snapshotなら通った > swift-DEVELOPMENT-SNAPSHOT-2019-06-02-a

あっ、 xcode-selectするの忘れてた、noobか

xcode betaでmaster通った。

https://forums.swift.org/t/questions-about-function-type-mangling/26360/5

Questions about (function type) mangling

Thanks for the swift replies! The purpose of mangling makes sense. Some concrete follow-up questions: Is it worth pursuing a more flexible scheme for mangling a list of function type modifiers? And is it possible to do so in a backwards-compatible way? Please see my post a...

3:06 AM

関数のmanglingでアトリビュートが一個しか保持できない仕様になっているので、 convention(c)とautoclosureを同時に使うとコンパイラがクラッシュするらしい https://bugs.swift.org/browse/SR-11027

2

https://github.com/apple/swift-llvm/blob/stable/lib/Target/X86/X86CallingConv.td#L504-L508

apple/swift-llvm

Contribute to apple/swift-llvm development by creating an account on GitHub.

7:24 AM

def CC_X86_64_C : CallingConv<[ // Pass SwiftSelf in a callee saved register. CCIfSwiftSelf<CCIfType<[i64], CCAssignToReg<[R13]>>>, // A SwiftError is passed in R12. CCIfSwiftError<CCIfType<[i64], CCAssignToReg<[R12]>>>,

1

7:24 AM

@Yuta Saito レジスタ割当ココにあった

すごいちゃんと宣言的に記述されてる

この謎言語で定義を書くと

7:26 AM

C++のヘッダーファイルが生成される仕組み。

7:26 AM

// build/Xcode-DebugAssert/llvm-macosx-x86_64/lib/Target/X86/X86GenCallingConv.inc static bool CC_X86_64_C(unsigned ValNo, MVT ValVT, MVT LocVT, CCValAssign::LocInfo LocInfo, ISD::ArgFlagsTy ArgFlags, CCState &State) { if (ArgFlags.isSwiftSelf()) { if (LocVT == MVT::i64) { if (unsigned Reg = State.AllocateReg(X86::R13)) { State.addLoc(CCValAssign::getReg(ValNo, ValVT, Reg, LocVT, LocInfo)); return false; } } } if (ArgFlags.isSwiftError()) { if (LocVT == MVT::i64) { if (unsigned Reg = State.AllocateReg(X86::R12)) { State.addLoc(CCValAssign::getReg(ValNo, ValVT, Reg, LocVT, LocInfo)); return false; } } } }

7:28 AM

LLVMかなり複雑で、CPUの種類とか亜種に応じた定義をいっぱい書いて、リゾルバが最終的にどういうバイナリにするか解決するみたいな雰囲気

なるほど

Integrating libSyntax into the compiler pipelineの最初のPRがrevertされた後に気配を感じなくなったので、わいわいswiftc発表までに内容固まるか不安だ... https://github.com/apple/swift/pull/25193

[Parser] Decouple the parser from AST creation (part 1) by jansvob...

Instead of creating the AST directly in the parser (and libSyntax or SwiftSyntax via SyntaxParsingContext), make Parser to explicitly create a tree of ParsedSyntaxNodes. Their OpaqueSyntaxNodes can...

ほんとだrevertされてる・・・

4:02 AM

でもこれ設計が悪いとかじゃなくて、自動生成系のファイルの兼ね合いでCIが壊れたってだけかな？

そうです。なのですぐ修正されたPRが来ると思ってたんだけど、なぜか一週間たってもPRない

4:06 AM

まだ全部読んで無いけど、設計はこれで良い気がしてる。今までのコアだった SyntaxParseActions を HiddenLibSyntaxAction でラップする感じ。

jansvoboda11さんのやつ、わりと早い時点でプルリク出ててしばらく動きなかったし、ゴリゴリ実装走ってるというより、結構コンパイラ内部のキャッチアップとか設計の打ち合わせに時間取ってるんじゃないかなという気がする

4:08 AM

SyntaxParseActions ←このActionってどういう概念なのか気になっているから解説待ってます

そんな感じする。 SyntaxParsingContext だけでも最初は意味不明だし

4:09 AM

それもカバーしたい！わいわいswiftcは現状の仕組みの説明が中心になりそう。その後に今後の展望を実装を添えてって感じ

SyntaxParsingContextが多分パーサのステートで、バックトラックとか中断/再開の絡みでうりゃうりゃやってるんかなと予想

SyntaxParsingContextはシンタックスツリー構築するステートかな。ルートのシンタックスノードに対してchildを1つしか持たないので、各シンタックスごとにcontext経由でノード登録するって仕組みだった。中断・再開はここの中でやってたかは忘れた (edited)

ふむふむ

中断・再開は違う場所だったような気もする。忘れたわ。 ASTContext とそこまでやってること違わない気はする。

4:15 AM

SyntaxParsingContext -> Syntax Tree ASTContext -> AST objects

4:17 AM

Contextが別々のアウトプットを生成するんだけど、各parse~メソッド内で SyntaxParsingContext と ASTContext への値注入を同じ場所でやってるのが今回のモチベーションのはず

SwiftSyntaxだと 1 + 2 * 3 みたいな式が演算子の優先度関係なくフラットになっちゃってるんだけど、これを階層付けするのってparserで解析したoperator precedenceだけでできるから、parserのlibASTで組み替えてるのかな？

8:26 AM

でもそうするとASTGen使う構成の場合、どういうふうになるんだろ

SquenceExpr から BinaryExpr への折りたたみはSemaでやってます。Parser は SequenceExpr 作るところまで。

おおそうなんですね

importしたモジュールも含めないと operator の優先順位つけられないので、Parserでは出来ないです。

あ〜

https://github.com/apple/swift/blob/505f9bac/lib/Sema/TypeCheckExpr.cpp#L424

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

ありがとうございます。TypeCheckExprか。

preCheckExpression という ConstraintSystem にかける前処理で呼ばれます。

@rintaro Opaque Result Typeの機能はswiftcに全部入ったんでしたっけ？ SwiftUIのシンタックス var body: some view {} をSwiftSyntaxに渡すと意図してないようなシンタックスで返ってきます。たぶんswiftc側の修正が必要？ some view が someView になってしまう。

 ▿ typeAnnotation : Optional<TypeAnnotationSyntax> ▿ some : SwiftSyntax.TypeAnnotationSyntax ▿ colon : SwiftSyntax.TokenSyntax - text : ":" ▿ leadingTrivia : Trivia - pieces : 0 elements ▿ trailingTrivia : Trivia ▿ pieces : 1 element ▿ 0 : TriviaPiece - spaces : 1 - tokenKind : SwiftSyntax.TokenKind.colon ▿ type : SwiftSyntax.SimpleTypeIdentifierSyntax ▿ name : SwiftSyntax.TokenSyntax - text : "someView" ▿ leadingTrivia : Trivia - pieces : 0 elements ▿ trailingTrivia : Trivia ▿ pieces : 1 element ▿ 0 : TriviaPiece - spaces : 1 ▿ tokenKind : TokenKind - identifier : "someView" - genericArgumentClause : nil - initializer : nil

ありゃ、なんでだろう。bugs に報告いただけますか？

分かりました！ swift-formatで遊んでたら気が付きました

libSyntaxは問題ないっぽい。-emit-syntaxの結果は正常に見えた。

@rintaro すみません！いろいろ問題を切り分けたらswift-formatが原因でした... お騒がせしました！ libSyntax/SwiftSyntax側では someがSomeTypeSyntaxになってるのを確認しました。

お、そうでしたか。swift-formatまだきちんと見られてないのですが、そういう書き換えもするんですね。

自分のレイヤーでもトークンを出力用に構築するとこがあって、そこでスペース足したり改行したりしてました。こんな感じです https://github.com/apple/swift-format/pull/10

[SR-11167] Ensure space between someSpecifier and baseType in ...

Produced source code with SomeTypeSyntax is not compilable because there is no space in the syntax Fixes SR-11167.

1:47 PM

swift-formatはまだ処理に凄い時間かかるので、そこが改善されるまで試用段階かなー

Token定義にオペレータがないのは単純にoperatorの量が多すぎるからですか？ precedenceの計算用にparser内では定義してた気はするんですが。+とか-。そもそもlexerではそこまで判定する必要ないのかな https://github.com/apple/swift/blob/master/utils/gyb_syntax_support/Token.py (edited)

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

Integrating libSyntax into the compiler pipelineの進捗が見えない！わいわいswiftcで紹介しようと思ったのに困った！

滞っていてごめんなさいー。

5:29 AM

https://github.com/apple/swift/pull/26403 さっき上げたこれで行ければいいんですけど、どうなるか。

5:30 AM

revert したとこ以降については、それはそれで進めていて、第一弾のこれがマージでき次第順次PR出していく予定です。

1

ちょうどPRあげたとこだったんですね、ありがとうございます！楽しみに待ってます。

sema読みづらい・・・ this経由とか参照型引数経由の副作用が追いきれない

参照型引数経由ばかりで慣れるまで読みづらいよね。parserまでしか読んだことないけど、semaはさらにやばそう

LValue-nessに関してSwiftcのConstraintSystemが何をやっているかわかってきたけど

8:30 AM

ピンポイント過ぎて大丈夫なのかコレって感じだ

https://twitter.com/omochimetaru/status/1161436976953749506?s=21

おも🐈ちメ🐍タル (@omochimetaru)

マージされた Semaコントリビュートの実績解除！ https://t.co/Tr1EcZZbRM

12:40 AM

↑「大丈夫なのか」って思ったところ大丈夫じゃなかった！

3

時々出てくる Qol ってなんだろう

1:55 AM

コンパイラの性能とか機能向上の文脈で出てくるけど Quality of life の事なの？

QoI (Quality of implementation)

Iか〜〜〜〜〜〜〜〜〜！！！ｗｗｗ

https://github.com/apple/swift/blob/master/docs/Lexicon.rst

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

Lexicon.rst見ればいいんですね、ありがとうございます。

QoI に関しては、ほとんどがdiagnostics改善という文脈で使われてますね。

なるほど

読んでたらいくつか変なとこ見つけたのでいろいろ落ち着いたら弄ってみる

In file included from /Users/omochi/work/swift-source/llvm/include/llvm/ADT/STLExtras.h:20: /Users/omochi/work/swift-source/llvm/include/llvm/ADT/Optional.h:141:3: error: unknown type name 'constexpr' constexpr Optional() {} ^ /Users/omochi/work/swift-source/llvm/include/llvm/ADT/Optional.h:141:13: error: constructor cannot have a return type constexpr Optional() {} ^~~~~~~~

3:10 PM

Xcode11 App Store版で、コンパイラのビルドがこんな感じで全然ビルドできなくなってしまった。

3:12 PM

他にもエラーが出てるんだけど、clangがC++ dialectをC++03相当で動作してるような気がする。

3:12 PM

こないだまでXcode-beta 11で問題なかったんだけど。

あ〜いけた。$ brew upgrade cmakeで解決しました。

3:37 PM

ninjaビルドだといけたので、cmakeのxcodeproj生成が怪しいと思ったのと、 -- The C compiler identification is unknown -- The CXX compiler identification is unknown ↑こんなメッセージが出ていた

差分としてビルド時のコマンドラインに-std=c+11が追加されてるわ。

masterビルドしようとするとsourcekitdが見つからなくてcmakeが通らない

CMake Error in cmake/modules/CMakeLists.txt: export called with target "swiftSwiftLang-macosx-x86_64" which requires target "sourcekitd" that is not in any export set.

(edited)

add_libraryでsourcekitdが登録されてるのは確認できた

7:16 AM

なんで動かないのか全く分からんのでここコメントアウトして無理やりcmakeだけ通した… https://github.com/apple/swift/blob/b8722fd7d4fc070d685dee2e1173ce180b4896c6/tools/SourceKit/CMakeLists.txt#L45-L47

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

Azure Pipelinesでswiftcをビルドしようとしたら成果物が大きすぎてディスク容量が足りなくなった https://dev.azure.com/kateinoigakukun/swiftwasm/_build/results?buildId=14

4:00 AM

困った…

草

4:00 AM

でかいマシンかりたら？

4:00 AM

あ

4:00 AM

PipelinesはCIのやつか

そうそう、publicリポジトリだと時間制限無しでビルドできるのでswiftcビルドできるじゃーん、って試してみたんですけど、

4:02 AM

5時間近く頑張った挙句にディスク足りなくて死にました

それでもタイムアウトはないのか、偉いな

4:02 AM

昔Travisでwebrtcをビルドしようとしたけどタイムアウトしちゃって無理だった

https://docs.microsoft.com/ja-jp/azure/devops/pipelines/agents/hosted?view=azure-devops#capabilities-and-limitations

Microsoft-hosted agents for Azure Pipelines - Azure Pipelines

Learn about using the Microsoft-hosted agents provided in Azure Pipelines

4:05 AM

ゴネればリソース増やしてくれるかな

とりあえずコンタクトしてみるのはいいんじゃない。

4:05 AM

ゴネるというのは気になるけど普通に。

compnardさんがAzureでswift for windowsをCIしてるやつはどうやってんのかな

4:06 AM

https://dev.azure.com/compnerd/windows-swift/_build?definitionId=2

4:06 AM

↑これ

お

https://dev.azure.com/compnerd/windows-swift

4:07 AM

Azure pipelinesってアイコンが出てるし

4:07 AM

やりたいことはいっしょそう

特に特別な事してなさそう。とりあえず聞いてみます

DebugビルドとReleaseビルドで必要となるディスク容量が大幅に違った様な。 (edited)

以前Debugビルドしたときには、60GB以上使ってた様な記憶がある。

6:27 AM

rintaroさんの記事によると、リリースビルドだと10GBくらい？ https://qiita.com/rintaro/items/2047a9b88d9249459d9a

Swiftコンパイラ開発環境構築 - Qiita

Swift がオープンソースになってしばらく経ちます。コンパイラや標準ライブラリの開発に手を出してみたいけど、リポジトリを落とした後どうしていいかわからない！という方のために、まずは開発環境...

なるほど、確かにwindows-swiftはリリースビルドですね

6:31 AM

swiftコンパイラとかllvmはリリースビルドで十分なんですが、stdlibは-Ononeでビルドしたいんですよね。そういう凝ったことできるのかな

過去ログ https://discordapp.com/channels/291054398077927425/291054454793306112/332495524772970496

1.7G ./Ninja-ReleaseAssert/swift-linux-x86_64 3.9M ./Ninja-ReleaseAssert/cmark-linux-x86_64 2.2G ./Ninja-ReleaseAssert/llvm-linux-x86_64 3.9G ./Ninja-ReleaseAssert 27G ./Ninja-DebugAssert/swift-linux-x86_64 5.1M ./Ninja-DebugAssert/cmark-linux-x86_64 42G ./Ninja-DebugAssert/llvm-linux-x86_64 68G ./Ninja-DebugAssert

1

6:35 AM

手元に残ってた成果物だとこんな感じでした

6:36 AM

llvmがヤバいのか

リリースビルドで試してみたところ無事ディスク足りたようで成功しました

9:36 AM

デバッグビルドが5時間かかったのに対してリリースビルドが3時間弱で終わった…

なんでリリースのほうが早いんだろう？

https://twitter.com/harlanhaskins/status/1182325909220556800?s=21

Harlan Haskins (@harlanhaskins)

This project has been so fun to work on and I'm super excited to see it open sourced. We've rewritten the Swift driver in Swift

https://t.co/emv2RdsnKO

おお！self-hostの第一歩だ

確かに一番外側のdriver層だったらビルドのブートストラップ問題もないな。

4:26 PM

内側の生swiftcでswiftをビルドしてそれでドライバーをビルドできる。

それにYamsが使われてるって、今朝jpsimが教えてくれた。 https://github.com/apple/swift-driver/blob/master/Package.swift

apple/swift-driver

Swift compiler driver reimplementation in Swift. Contribute to apple/swift-driver development by creating an account on GitHub.

2

litのテストケースでよく使われてる -### って何の機能ですか

見たことなかった

clangにはそのオプションがあるみたいですね。

$ clang -help OVERVIEW: clang LLVM compiler USAGE: clang [options] file... OPTIONS: -### Print (but do not run) the commands to run for this compilation

clang由来のオプションだったんですね

1:32 AM

swiftcのヘルプには出てこないけどテストケースを見るにswiftcにも同じオプションが実装されてるのか

LITもclangもLLVMプロジェクトだから由来は同時そう

検索しにくい名前で非常に困ってた

1:34 AM

後学のために聞きたいんですが、 @norio_nomura さんはこれどうやって見つけられました？

ローカルのリポジトリをVSCodeで検索しました。

なるほど、clangの方は関係ないやと思って全く見てなかった

あ、swift/utils/update-checkoutで取得できるリポジトリ達を置くディレクトリ全体で検索するのがポイントですかね。 (edited)

1

1:49 AM

そういえば、swift/utils/update-checkoutはLLVM monorepo transitionを自動で処理してくれるのかな？ https://forums.swift.org/t/llvm-monorepo-transition-happening-on-thursday-the-17th-of-october/29674

LLVM monorepo transition happening on Thursday, the 17th of October

Hi, I would like to provide an update to the monorepo transition posts (https://forums.swift.org/t/llvm-monorepo-transition/25689 and https://forums.swift.org/t/llvm-monorepo-transition-update/27079) where I announced that Apple is working on the LLVM project monorepo transi...

それ気になってるけどそもそもなんもわかってない

手作業でllvm-projectをクローンしてclang, clang-tools-extra, compiler-rt, libcxx, lldb, llvmを削除してからswift/utils/update-checkout --scheme masterを実行したら、削除したモノ達と同名のシンボリックリンク達が作られた。 (edited)

最近[Requestify]ってついた改修が複数発生してるけど

1:06 AM

どういう目的なのか気になってるいまのところの予想 1. ただの内部的なリファクタリング 2. これをやらないと循環するケースとかでバグが取り切れない 3. LSPみたいなプロセス跨いでインテグレートするための基盤

1:07 AM

https://github.com/apple/swift/search?q=requestify&type=Commits

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

Requestifyってそもそもどういう意味なんですか？

よくわかってないですがなんかリクエストオブジェクト作って(非同期で？)結果が戻るような、コンパイラの中の機能をAPI的な感じにしてるような箇所があるので、そういう風な感じにするやつだろうか？

あ、なるほど。Requestifyに変えるって意味か。

https://github.com/apple/swift/commit/d07efd37e01458708543a74dfb6e133bafbe55b6

Requestify the mangling-to-metadata APIs. · apple/swift@d07efd3

Note that I've called out a couple of suspicious places where we are requesting abstract metadata for superclasses but probably need to be requesting something more complete.

Requestifyプロジェクトみたいなのがありそう。ってこれか。

型がなんかホゲレスポンスとかに変わってる

確か結果のキャッシュをどうするかとかを定義する型です

1

1:13 AM

計算中にまたリクエストがあった場合にどうするか、とか

非同期ではないです。ASTを一通りなめて全部をタイプチェックするのではなく、必要になったときに必要な分だけタイプチェックする等、lazyに評価をしていきましょうという取り組みです。ついでにリクエストに対する結果はキャッシュされるので、無駄が起こらないはずというのと、

1:14 AM

あと、循環ケースが自動で検出される仕組みになっているので、デバッグが楽になる。

おおー

1:16 AM

その辺の結果のキャッシュのロジックを共通化してるんですかね

https://github.com/apple/swift/blob/master/docs/RequestEvaluator.md

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

お、文書あった読みます

ですね。cache と circular dependency 検出が自動で手に入るので嬉しい。

なるほど〜ありがとうございます

fine-grained tracking and visualization of dependenciesなるほどー

ちなみに rust にも Querify という同じような取り組みがあります。 https://github.com/rust-lang/rust/issues/47660

1

ほお！Rustを真似したのかな〜とか想像してました、同時期に同じようなことしてるのはなんか他の言語で先行事例があるんですか？

どうなんでしょうねー。世界を大きなクエリーの依存グラフとしてモデル化するっていうのは最近はやっているのは事実っぽいんですがー。

ほお〜

1:45 AM

Prior art Rust's compiler went through a similar transformation to support demand-driven compilation. We should learn from their experience!

まんまだｗ

Rustの話はかいてあった。

Graydon Hoare (Rust の父的な人）が Swift に導入しました

https://github.com/apple/swift/commits?author=graydon

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

2:06 AM

あ〜このアイコンちょいちょい見かけてた

2:06 AM

Rustの偉い人がAppleに移ってたんですね

コンサルタントだったんじゃないかと思います

2:09 AM

昔Request化のリファクタリングに挑戦してみたかったんです。なぜかw

Christopherさんが？ > 挑戦してみたかった

はい

2:15 AM

Graydon 氏じゃなくてw (edited)

それで詳しいんですね

https://forums.swift.org/t/error-running-build-script-no-architectures-to-compile-for/31050

Error running build-script: "No architectures to compile for"

Hi all, I'm having problems building the compiler from the master branch. I started running ./swift/utils/update-checkout --clone-with-ssh, which worked fine. Then tried building using ./utils/build-script --xcode --release-debuginfo --force-optimized-typechecker --swift-...

10:09 AM

↑この問題でmasterがビルドできないが、

10:10 AM

最寄りのstable snapshotの5.1.2は、

10:10 AM

update-checkoutはllvm monorepo transition適用済みなのに対して、

10:10 AM

build-scriptは適用前になっていて

10:10 AM

--cloneを付けてもswift-source/llvmが落ちてこないが、ビルドではそれを探すので死んでる

10:11 AM

今5.1.1を試しているところ。

手元のクローンだと、llvmはllvm-project/llvmへのシンボリックリンクになってる。

llvmを削除してから、 update-checkout --clone しても、生成されなくないですか？

10:22 AM

過去のコミットをベースに、llvmを置いてある状態からだと、移行はできるようなものかも。

llvm-projectを手動でクローンしてllvmとか削除した後で、utils/update-checkout --scheme masterしたらシンボリックリンクが作られたと記憶。 (edited)

ふむふむ

下記シンボリックリンクが作られてる。

./clang -> /Users/norio/github/swift-dev/llvm-project/clang ./clang-tools-extra -> /Users/norio/github/swift-dev/llvm-project/clang-tools-extra ./compiler-rt -> /Users/norio/github/swift-dev/llvm-project/compiler-rt ./libcxx -> /Users/norio/github/swift-dev/llvm-project/libcxx ./lldb -> /Users/norio/github/swift-dev/llvm-project/lldb ./llvm -> /Users/norio/github/swift-dev/llvm-project/llvm

うーん、作られなかったのはなんだろうなあ

10:30 AM

今のmasterだともうできない

そうなんだ。

monorepo transitionが完了している感じがします（その先で↑のissueを踏むのでよくわからないが

https://github.com/apple/swift/commit/5c53756ef6642a0cbcf2e40b3f034320a0ff6eb2

[update-checkout] Remove the symlink from update-checkout because ...

…are using llvm projects directly

めっちゃ最近だった

10:33 AM

うげー5.1.1もとおらね〜〜〜

ninjaでもだめですか？

In file included from /Users/omochi/work/swift-source/swift/stdlib/public/runtime/MetadataLookup.cpp:34: /Users/omochi/work/swift-source/llvm/include/llvm/ADT/PointerUnion.h:162:1: error: too few template parameters in template redeclaration template <typename... PTs> ^~~~~~

10:34 AM

ninjaは試してないです

10:35 AM

あれ？llvmのcheckoutが5.1.1 snapshotになってないな

5.1.1のswift/utils/update_checkout/update_checkout/update_checkout.pyはsymlink作る処理入ってない。 (edited)

10:40 AM

5.1.2は入ってる。

symlinkの処理って、

10:41 AM

どうやって叩くんです？

10:41 AM

--scheme masterだとその処理に行く前に、

10:41 AM

自分自身がmasterになっちゃいますよね

swift-5.1.2-RELEASEをチェックアウトすれば良いのでは？

--tag swift-5.1.2-RELEASE？

(cd swift; git checkout swift-5.1.2-RELEASE)

ん、そのあと、

10:46 AM

update-checkoutをどういうオプションで発火するのかです

10:46 AM

update-checkoutがsymlinkの処理に行く前に、update-checkout自身が自身を含むswift repositoryを

10:46 AM

更新したりすると

10:46 AM

てか今回に限らないんですが、

10:47 AM

update-checkoutの働きがバージョン間で変わってる時に

10:47 AM

update-checkout自身がupdate-checkoutで更新される挙動がどういうポリシーなのかよくわからない

10:48 AM

一度発火してるupdate-checkoutはその時のソースのままpythonプロセスに載ってるんだろうか？自己を再度発火したりはしていない？

その後はswift/utils/update-checkout --tag swift-5.1.2-RELEASEで良いのでは。

10:49 AM

swiftリポジトリ自体は変わらないし。

一回目のgit checkoutでupdate-checkoutのバージョンを選択しつつ、 update-checkout自体には--tagを与えてバージョン変動を防止、か。

一度symlinkが作られた後は、5.1.1とかには戻せない様な気もする。

なぜswift-5.1.2-RELEASEはswift-5.1-branchからではなくswift-5.1-branch-08-28-2019から作られたのだろう。

そのへんてこなブランチなんですか・・・？

appleがXcodeベータに入れるswiftをビルドする時に、一時的に作るブランチかな？

ああ〜。

swift-5.1-branchに入ってて、swift-5.1.2-RELEASEに入ってない変更たくさんある。 https://github.com/apple/swift/compare/swift-5.1.2-RELEASE...swift-5.1-branch

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

お、差分の中にOne-way constraintsがある、これ気になっている（まだわかってない

11:36 AM

話題のapi-checkerもか

11:36 AM

5.1.2は5.1.1の安定化リリースで、5.2的な機能追加は5.1ブランチでやってる感じ？

いや、それはmasterブランチの役割じゃないの？

https://github.com/apple/swift/compare/master...swift-5.1-branch 5.1に入ってて、masterに入ってないコミット

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

11:39 AM

[Constraint solver] Introduce one-way constraints. … 75f88ca 、どっちにも表示されてるな。

11:39 AM

え〜

11:40 AM

いまmasterと5.1結構乖離してるんですね、なにこれー

いや、それはそういうものでしょ。

新機能はとりあえずmasterに入っていくものかと思って。

ああ、5.1にしか入っていないってことですか、ふむ。

https://github.com/apple/swift/commit/3c69f6a305274f8f4e68a761d7c445b308fdf9f1

[Constraint solver] Introduce one-way constraints. · apple/swift@...

Introduce the notion of "one-way" binding constraints of the form $T0 one-way bind to $T1 which treats the type variables $T0 and $T1 as independent up until the point where $...

11:48 AM

同じコミットの3c69f6a（ハッシュ違い）がある

11:48 AM

masterブランチ向けと5.1ブランチ向けに

11:48 AM

同じコミットをそれぞれrebaseして出してるのかも

Cherry-pickって書いてある。 https://github.com/apple/swift/pull/26661

[5.1] One-way constraints for function builders by DougGregor · P...

Cherry-pick the work to enable one-way constraints for function builders to the 5.1 branch as an experiment. Implements rdar://problem/50150793.

https://github.com/apple/swift/pull/25983

[Constraint solver] Introduce one-way binding constraints. by Doug...

Introduce the notion of "one-way" binding constraints of the form $T0 one-way bind to $T1 which treats the type variables $T0 and $T1 as independent up until the point where $T...

11:50 AM

master向けがこっちで、5.1ブランチ向けに[5.1]ってつけて別PRなんですね。

よくあるパターンですね。

そうすると、5.1.2に入ってないものが5.1に入ってるのは特に変じゃなくて、5.1.3で出ることが期待できるし、

11:53 AM

同じようにmasterにも入ってるから5.2はそのまま全部入りになると

11:53 AM

普通か。

11:53 AM

cherry-pickってマージコンフリクト考慮されるんでしたっけ

11:53 AM

それとも、5.1からmasterへのマージはやらないのかな。

11:54 AM

常に両方に出してればそれでいいけど、うっかり5.1の方だけで重要な作業をしてしまう可能性はないんかな、気をつけるのかな。

Cherry-pickされてると、ブランチ間のコミットログの差分には出るけど、実際のdiffには出てこない。

ならまあ見てチェックできるか。

swift-5.1-branchとswift-5.1.2-RELEASEの違いの場合、チェリーピックとか関係ないから、swift-5.1.3-RELEASEがswift-5.1-branchを元に作られると、かなり変更が大きくなるかな。

なるほど

swift-5.1-RELEASEとswift-5.1.1-RELEASEの違いが少なすぎてびっくりした。 https://github.com/apple/swift/compare/swift-5.1-RELEASE...swift-5.1.1-RELEASE

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

バージョンしか変わってないですね

12:04 PM

ん〜これはどういうことなんだ

12:04 PM

一応バージョンあげといたほうが一緒に出荷されたXcodeのリビジョンとか絞りやすくていいねみたいな感じかしら

swift-5.1.2-RELEASEタグ、付け直されてる… https://github.com/apple/swift/commits/swift-5.1.2-RELEASE

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

12:59 AM

https://forums.swift.org/t/where-is-the-source-code-for-swift-5-1-2/31123

Where is the source code for Swift 5.1.2?

While compiling Swift 5.1.2 on Linux I have found the following issues and would like some clarification on whether this is a problem and if a bug should be filed. The swift-5.1-branch which Swift 5.1.2 should be built from is still versioned at 5.1.1 The tag swift-5.1.2-RE...

1:01 AM

バイナリも更新され~~たぽい？~~てた。 (edited)

付け直しとは無茶するなあ

swift-5.1.2-RELEASEまでと違い、swift-5.1.3-RELEASEはちゃんとswift-5.1-branchから作られてた。 https://github.com/apple/swift/compare/swift-5.1-branch...swift-5.1.3-RELEASE

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

swiftc初心者です。Swift 5かなにか最近、witness tableの挙動かわりましたか...?

7:38 AM

あ、勘違いだった。変わってなかった。

swiftc コマンドにソースファイルを引数として与える場合に、トップレベルに実行文が書けるモードになるのって、「引数が1ファイルの場合」または「ファイル名がmain.swift」っぽく読めるんですけど、そうなん？ (edited)

7:57 AM

https://github.com/apple/swift/blob/10936f6d4990df3bcb883da1477198358a87161e/lib/Frontend/Frontend.cpp#L495

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

7:57 AM

https://github.com/apple/swift/blob/10936f6d4990df3bcb883da1477198358a87161e/lib/Frontend/Frontend.cpp#L512

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

7:58 AM

「これがメインだよ」ってオプションが無いのが気持ち悪い

あ、なんかそれは思った事ある

やはりそうなのか

@Yuta Saito SwiftRT-ELF.cppを読んでいたんだけどさ

10:00 AM

Mach-Oの場合は getsectiondata っていうAPIがあるからそれを使うけれど

10:01 AM

ELFの場合はそのようなものがないので・・・

10:02 AM

まず、LLVM側で、objファイルを作る時にセクションの先頭と末尾に __start_<section> と __stop_<section> というシンボルを生成する。

10:02 AM

そのように思った根拠↓ https://reviews.llvm.org/D10901

10:03 AM

次にランタイム側で __attribute__((__constructor__)) を付けた関数を定義しておくことで、イメージがロードされた時にこれが呼び出され・・・ (edited)

そうそう

#define DECLARE_SWIFT_SECTION(name) \ __asm__("\t.section " #name ",\"a\"\n"); \ __attribute__((__visibility__("hidden"),__aligned__(1))) extern const char __start_##name; \ __attribute__((__visibility__("hidden"),__aligned__(1))) extern const char __stop_##name; extern "C" { DECLARE_SWIFT_SECTION(swift5_protocols)

10:03 AM

このように書いておくことで、 asm文を使ってセクション名を指定しつつ、 extern宣言で、LLVMが埋め込んでおいた __start_section と __stop_section のシンボルをリンクさせて・・・ (edited)

10:04 AM

#define SWIFT_SECTION_RANGE(name) \ { reinterpret_cast<uintptr_t>(&__start_##name), \ static_cast<uintptr_t>(&__stop_##name - &__start_##name) } ... SWIFT_SECTION_RANGE(swift5_protocols),

10:05 AM

このようにすることでそのstartシンボルのアドレスとstopシンボルのアドレスから、イメージ中の、セクションデータのメモリアドレスとサイズを得る

10:05 AM

って仕掛けって理解でいいのかな？

そうですね。

10:05 AM

細かい話だと、上のインラインアセンブリはセクションを指定するためのものではなくて、

10:07 AM

IRGenが吐くセクションが空のときでもセクションが常にオブジェクトファイルに含まれるようにするためのやつです

10:08 AM

あと __start __stop はLLVMが出力するんじゃなくて lldが全てのオブジェクトファイルをリンクするときに作ります

あ〜れ？あ、じゃあ、これは、

10:09 AM

SwiftRT-ELF.cpp は、それぞれのSwift dylib自体に取り込まれて

10:09 AM

自分自身の中にあるstartとstopを探して自分の中身をグローバルに登録するための

10:09 AM

初期化処理を埋め込んでるのか。

10:10 AM

なんとなく別のオブジェクトになってるイメージがあった。

10:11 AM

lldが全てのオブジェクトファイルをリンクするとき

executableかdylibになる時？

初期化処理自体はそれぞれのdylibに対して行われるけど結局１つのグローバル変数にprotocol conformanceとかが登録されるはず

うん、そこはそうだった。

10:12 AM

namespace { static const swift::MetadataSections *registered = nullptr; void record(const swift::MetadataSections *sections) { if (registered == nullptr) { registered = sections; sections->next = sections->prev = sections; } else { registered->prev->next = sections; sections->next = registered; sections->prev = registered->prev; registered->prev = sections; } } }

これでリンクリストに追加してた。 (edited)

executableかdylibになる時？

dylibの場合はそうです

10:13 AM

それです

ただこの swift::MetadataSections * swift::(anon ns)::registered が

10:13 AM

どうやって１個になってんだ

10:14 AM

あー SwiftRT-ELF.cpp から作られるstatic libraryは個別にリンクされるけど、 ImageInspectionELF.cppからの成果物は本体実行ファイルだけにリンクされるのか？

えーとそこは別のdylibになってるはず

10:14 AM

名前なんだったかな…

たしかにビルド単位が別だな

10:15 AM

SwiftRT-ELFはswiftImageRegistrationObjectELFで

libswiftImageInspectionShared.dylib (edited)

ImageInspectionELFはswiftRuntime-macosだ

ここですね https://github.com/apple/swift/blob/c662a915780a357d9313956f79dae8c4e6df82db/stdlib/public/runtime/CMakeLists.txt#L98-L103 (edited)

apple/swift

The Swift Programming Language. Contribute to apple/swift development by creating an account on GitHub.

おーなるほど > # These two libraries are only used with the static swiftcore

10:18 AM

two librariesってなんだ？ L158のadd_swift_target_library(swiftImageInspectionSharedObjectかな

10:18 AM

そっか、libSwiftCore.dylibに含まれてれば、アプリ実行ファイルはそれをdynamic loadして動くんだから

10:19 AM

グローバル変数としてはSwiftアプリプロセスに1個になるか。

10:19 AM

てかよく考えたらランタイム関数がそこに入ってて、そのグローバルを触るわけだからそれで自然だな。

結構static executableと差分があるんですよねー

この辺の成果物を自分でハックして実行時に引っ張れないか考えてるんだけど

10:20 AM

ランタイム側の登録されたデータ構造は、大体、匿名namespaceに入っててシンボルが取れない

10:20 AM

あと、今話してわかったけど、ELFの場合は、 __attribute__((__visibility__("hidden"),__aligned__(1))) extern const char __start_##name;

10:21 AM

このスタートシンボルが visibility hidden ってことは

10:21 AM

外のobjectからリンクできない・・・？

10:21 AM

swift_image_constructor は同じobjectの中だからこれが見えて、スタートシンボルが取れて、その場でグローバルに登録しちゃうけど

10:21 AM

外側から後から同じことができないよね。

あー、そうか、自分で作ったオブジェクトファイルのstart, stopしか取れないのか

10:23 AM

なるほど

10:23 AM

こういうことさせないために匿名namespaceになってるのでは…

visibility hiddenだし、リンカーがリロケートした後は、消えてるないし、シンボルテーブルとかで公開していないんじゃないか

10:23 AM

そう、２段階あって

10:24 AM

個別のdylibの中のセクションデータを読み取るステージ（これはELFとMachで実現方法が異なる

10:24 AM

その後、共通のランタイムライブラリの中のグローバル変数に登録するステージこっちは型付けされててコードが共通

10:25 AM

だけど、前者についてはMachはgetsectiondataでできそうだけどELFはこのような都合のために無理そう？

10:25 AM

後者についてはC++の文法的に隠れてるのでコンパイル後のシンボル名もわからなそう。（てかstaticだからこれもまたエントリが無いかも

10:26 AM

させないために匿名namespaceになってる

はい、まあ・・・。

実行ファイルにread権限が付いてれば実行時にロードされるバイナリとは別にセクションをスキャンして…

それは、ファイルシステム側にある実行ファイルそのものを読み取るってこと？

そうです

10:27 AM

あーでもdylibを追っかけないといけないのか

情報は取れそうだけど、プロセス上のメモリアドレスはわからないよね

10:28 AM

あーそうだね、ロードされるdylibのパスを知るのはもっと難しそう。

10:28 AM

うーむ、こういうのって、一種のセキュリティとしてこのように考えて作られてるのかな。

10:28 AM

同じプロセス空間に自分のコードが注入できる状況にも関わらず手も足も出ないぞ。

なんかどうにでもなる気がするんだけどなぁ

でもなるとしたら、このスタートシンボルのテクが、いらんはずだよね。

とりあえず理解は進んだ、ありがとう

僕もちょっと考えてみます

10:44 AM

要は定義された参照可能な全てのプロトコルを洗い出したいんですよね？

そうです

10:45 AM

あとマングルされてない名前も取り出したい(これは残ってるかどうかわかってないけど

10:46 AM

最終的に作りたいもの func protocol(moduleName: String, name: String) -> PrtDtor (edited)

そうか、ProtocolDescriptorのシンボルはコンパイル時に決定できるからランタイムライブラリにそれを動的に取得するようなAPIが無いのか

そうなんですよ