swift-developers-japan - swift-syntax

ユーザーとしては、文字列を取得した時はクオート無くなって欲しいと思ってイシュー書いた https://bugs.swift.org/browse/SR-10241 (edited)

https://twitter.com/olebegemann/status/1113001026968326144 これはうれしい

Swift AST explorer by @k_katsumi is a fantastic tool for understanding how the Swift compiler parses source code: https://t.co/W4n1el2I3S

9

また壊しちゃったかも... https://swift-ast-explorer.kishikawakatsumi.com

1

大丈夫じゃないかな？

12:24 AM

ただ結果が返ってこなくなったりすることがあるのは認識していて、今は適当に再起動してるのですが、なんか手がかりがわかることがあったら直したいので教えてください。

直ってるの確認しました！ありがとうございます！それが入力してるコードに共有点あまり無いので、まだ手がかりなしです...

どうも。まあたぶん適当に作った部分だと思うんですよね。。。

googleのswift-format, swift buildはできたんですけど、generate-xcodeprojができないんですが、なにか知ってる人いますか？

[omochi@omochi-iMac-PC43 swift-format (format=)]$ swift build warning: invalid duplicate target dependency declaration 'swift-build' in target 'FunctionalPerformanceTests' warning: invalid duplicate target dependency declaration 'swift-package' in target 'FunctionalPerformanceTests' [omochi@omochi-iMac-PC43 swift-format (format=)]$ 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' error: fatalError

3:39 AM

あ

3:39 AM

Xcode-betaなのが駄目だったみたいです、解決しました。

TransformerはASTGenにリネームするみたい https://forums.swift.org/t/integrating-libsyntax-into-the-compiler-pipeline/26605

Integrating libSyntax into the compiler pipeline

Hey all, As per the GSoC announcement, @jansvoboda11 is working on Integration of libSyntax with the compiler pipeline with @rintaro as his mentor. I'd like to provide more details on what the project entails and what changes you should expect to see coming to the Swift repo...

3:18 AM

リバートされてるけど、最初のPRがこれ 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...

いろいろリネームされてるよね

ASTGenのほうがしっくりくるしOK

IRGenとかと揃えてんのかな？

brentdaxさんはそう言ってるはず https://forums.swift.org/t/integrating-libsyntax-into-the-compiler-pipeline/26605/2

Integrating libSyntax into the compiler pipeline

This is super-exciting! Two questions: Are there any plans to systematically test that the new parser/transformer doesn’t produce different ASTs from the old parser? For instance, I could imagine comparing the output of -dump-parse on some large corpus of Swift code to s...

dependencies: [ .package(url: "https://github.com/apple/swift-syntax.git", .revision("xcode11-beta1")), ],

2:48 AM

dyld: Library not loaded: @rpath/lib_InternalSwiftSyntaxParser.dylib Referenced from: /Users/omochi/Library/Developer/Xcode/DerivedData/SwiftTypeInference-ctmynziujqzotxcamwbdvzlrnvfq/Build/Products/Debug/SwiftTypeInference Reason: image not found

2:49 AM

Xcode11 beta4で動かせない

swift-formatのSwiftSyntax依存は、こう書いてあるね https://github.com/apple/swift-format/blob/af0f3cf540ae4571e848e871e7b3cfb308576c98/Package.swift#L24-L27

apple/swift-format

Formatting technology for Swift source code. Contribute to apple/swift-format development by creating an account on GitHub.

おっ

ちょうどswift-formatを眺めていた

だめだ、同じエラー

2:55 AM

あ

2:55 AM

$ swift run だと行ける

2:55 AM

XcodeのRunがだめだ？

XcodeのSchemeの設定で、Environment variablesに LD_LIBRARY_PATHを /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx

3:23 AM

と設定したらいけた。

Xcode 11が、/usr/lib/swiftが存在する環境しかサポートしなくなったから、rpathにXcode.appバンドル内のswiftライブラリディレクトリを設定しなくなったのね。

なるほど・・・うーん・・・整った環境ではそれでいいけどもなあ

SwiftPM的には「rpathを設定しなくなった」だけど、Xcode的には「元々そんな設定してない」かな。

Function Builders使ってSwiftSyntaxを構築するの良さそう https://github.com/akkyie/SyntaxBuilder

akkyie/SyntaxBuilder

A toy Swift code generator based on SwiftSyntax, leveraging Function Builders. - akkyie/SyntaxBuilder

1

良さそう

SwiftSyntaxで数行のコード生成するだけでもコード量が多くて大変だった

6:44 AM

これがSwiftSyntaxにそもそも入りそう https://twitter.com/akyrtzi/status/1152001576669552640?s=20

Argyrios Kyrtzidis (@akyrtzi)

@akkyie Hey this is really cool! Are you interested in contributing this to the swift-syntax repository?

おおっw

話変わるんですが、このエラーの直し方分かりますか？ SwiftSyntax parser library isn't compatible たぶんパーサーのswiftparse_syntax_structure_versioning_identifier とSwiftSyntaxが一致してないんですが、masterのSwiftSyntaxがどのパーサーとcompatibleか調べる方法が分からない環境: SwiftSyntaxはmaster, Xcode 11 beta 4 (edited)

https://github.com/apple/swift/blob/master/utils/update_checkout/update-checkout-config.json#L64

apple/swift

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

7:10 AM

↑の定義からすると、コンパイラのmasterはSwiftSyntaxのmasterと紐付いてるんじゃないか？

7:10 AM

あと、 https://github.com/apple/swift-syntax/releases

apple/swift-syntax

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

7:10 AM

↑のDEVELOPMENT-SNAPSHOT-2019-07-10とかは、

7:11 AM

同じ日付のコンパイラのスナップショットと紐付いているんじゃないかなあ？

なるほど。てことはmasterでやってみれば良いか！ただswiftcのビルドが途中で失敗するので生成されるSyntaxNodes.swiftにあるハッシュが更新されてるか不明で困った

7:21 AM

家帰ってmac miniでやってみます。ありがとう！

1

masterとswift-5.1-branchのどちらも、ハッシュの元となってるgyb_syntax_supportは7/2~3以降更新されてないから、どちらのsnapshotでも動くかと。 https://github.com/apple/swift/commits/master/utils/gyb_syntax_support https://github.com/apple/swift/commits/swift-5.1-branch/utils/gyb_syntax_support (edited)

apple/swift

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

apple/swift

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

そうか、コミットヒストリー見ても分かったのか。ありがとうございます！

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

[Parser] Decouple the parser from AST creation (part 2) 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...

10:44 AM

パート2だ

SwiftSyntaxにfunction builders適用するPR https://github.com/apple/swift-syntax/pull/139

Initial implementation of declarative and type-safe wrapper by akk...

Implemented declarative and type-safe wrappers around SwiftSyntax, using @_functionBuilder. (@akyrtzi thank you for encouraging me to upstream it!) Example Usage let format = Format(indentWidth: 2)...

前に北さんが貼ってたやつですよね、すごくいい

良いアイデア

@Kishikawa Katsumi すみません、またswift ast explorer壊したかもしれないです...

直しました。ちょうどSSHがつなぎっぱなしになってた。

わろた

なんかちょっとずつ使ってる人増えてるみたいで昨日はAirBnbの人からTwitterでまったく同じこと頼まれた。

4:15 PM

その人も言ってたんですけどマルチラインString使ってました？

ありがとうございます！いえ、使ってないです

じゃあそれは関係ないか。やっぱり実行ボタンを付けるのが良さそうだな。

原因究明は難しそうですね...

自分で使っててもそっちの方が使いやすい気がしているし。

4:18 PM

ローディングのままってことはSwiftSynataxからの応答が帰ってこないんでしょうねえ。

4:18 PM

なんでかはわからないけど、、、

ユーザーのインプットをログとしてどっかに一時的に置いておくのは良いかも。時間もお金も余裕があったら

それはそれとしてPlaygroundもそうだけどパーマリンクはあると便利だなとは思っています。

それは相当便利ですね！

再起動は一瞬だから１時間に１回再起動させてしまおうかな。かなり敗北だけど、使ってる人がいるなら仕方ない。

もしハングする入力が存在するなら、それ発見できたらかなりの貢献ですね。

この状況だと仕方ないですねー。僕は今まで2回しか壊してないはずだから、頻度はかなり低いはず

さすがに私の書いた部分だと思うんですよね。

https://forums.swift.org/t/integrating-libsyntax-into-the-compiler-pipeline/26605/13

Integrating libSyntax into the compiler pipeline

Hey all, I'd like to give an update on this. @rintaro has picked up and continued development on this since Jan's GSoC project concluded, but unfortunately finishing this project is going to take significantly longer than we anticipated. There are other more urgent tasks that...

2:18 AM

リンタロープロジェクト止まっちゃった

4

SwiftcKaigiで話そうと思ってたのに...

久々にSwiftSyntaxを触ったら SyntaxTreeDeserializer が消えていたんですが、byte treeってどうなったんでしたっけ？

12:28 PM

SyntaxTreeDeserializer をSourceKitから引き抜いたbyte treeをデシリアライズするために使っていたので、代替になるようなAPIがあれば知りたいです。

ServerSideSwiftの案件で、Vapor/Reactの連携構成を組んでて、連携部分を型安全にするために、SwiftコードからTypeScriptを自動生成する仕組みを、 SwiftSyntaxを使って作っていて、いい感じなのだが

12:23 PM

Xcode12.5用のSwiftSyntaxをリポジトリから依存に組んであり、

12:23 PM

Xcode13 beta で開発するためには元リポジトリの依存先の依存先のSwiftSyntaxのtagを切り替えないといけないんだけど

12:24 PM

良い方法ってあるかしら。

SwiftからTypeScript生成するの自体に興味がある

https://github.com/omochi/CodableToTypeScript/blob/main/Tests/CodableToTypeScriptTests/CodableToTypeScriptTests.swift

omochi/CodableToTypeScript

Generate typescript code for typing JSON from Swift Codable. - omochi/CodableToTypeScript

12:30 PM

こんな感じ

12:31 PM

TypeScriptの場合 import 文の生成も必要な事に気がついたので手元にはその実装もある

おもしろい、使ってみる

これ、enumも渡せるのが頑張ってるところで、

12:33 PM

(associated value付きの)enumをcodableにするためには

12:33 PM

Xcode13betaでSwfit5.5を使うか、

12:33 PM

https://github.com/omochi/SE0295Polyfill

omochi/SE0295Polyfill

You can generate Swift source code of enum with associated values which complies with SE-0295. - omochi/SE0295Polyfill

12:34 PM

↑こちらのライブラリでコード生成すると使えるよ。

associated valueできるのって見てたけど、Swift 5.5なのか

そうなんや

12:35 PM

13beta待ちきれなくて作ったサーバサイドで安定してるかわからんしiOSがサブミット出来るのだいぶ先だろうから。

https://github.com/apple/swift-package-manager/blob/main/Documentation/Usage.md#top-of-tree-development

apple/swift-package-manager

The Package Manager for the Swift Programming Language - apple/swift-package-manager

12:48 PM

editモード使えばいいのか。

@Yuta Saito @rintaro Appleが配布してるXcode13 betaに同梱されてるSwiftコンパイラのコミットを特定する方法ってありますか？ Xcode13 betaと一緒に動くSwiftSyntaxのコミットバージョンを特定したいです。

あー、なんか、それ難しかった気がする…

知りたい

なんか、「このコミットからブランチしてる」とかそういう風じゃなくて (edited)

3:14 AM

これとあれとあれに内部のこれとあれをいれたこれが入ってます

3:14 AM

みたいな感んじだと聞いたような…

niw

これとあれとあれに内部のこれとあれをいれたこれが入ってます

それは、 apple/swift をチェックアウトして、そのときの update-checkout-config.json ? を見たらわかるんじゃなかったっけ

Xcodeのclangコミットが知りたくて過去に聞いたときにそんな感じだと聞いた気がする

むむむむ

build-scriptに swift-compiler-version というのが指定できて、それがswiftc --versionに記載されてるっぽい

@Iceman わい、Xcode13beta落とせないんで、頼む・・・

え、まだダウンロードしてなかったのか…

3:20 AM

ギガ節約

Yuta Saito

build-scriptに swift-compiler-version というのが指定できて、それがswiftc --versionに記載されてるっぽい

build-script って具体的にどのリポジトリの何を指してますか？

apple/swiftのutils/build-scriptですね。で、これを実行するのはApple側なのでパラメータに何を渡してるのかは結局わからないです…

1

3:24 AM

ここがバージョン表示のロジック https://github.com/apple/swift/blob/0cd0cbc02adf2f794570cf102fde08089d7fdae2/lib/Basic/Version.cpp#L412-L422

apple/swift

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

niw

え、まだダウンロードしてなかったのか…

昨日寝る前にキックしたら３時間って出たんだけど５分ぐらいしたら１２時間に伸びておそらく低速化させられたから止めた。

1

omochimetaru

昨日寝る前にキックしたら３時間って出たんだけど５分ぐらいしたら１２時間に伸びておそらく低速化させられたから止めた。

悲しみ

正式版が出ると https://github.com/apple/swift-syntax/blob/main/README.md に対応タグが書かれるんですけど、今はまだ書かれてないですね。

はい。表に無いなと思って・・・

コンパイラ側にApple版だけのシンタックス変更がある場合、そもそも対応するコミットがgithubに無いっていう状況もありうるので、ちょっと明日確認させてください。

1

Apple版だけのシンタックス変更がある場合

この可能性があるのかw

rintaro

コンパイラ側にApple版だけのシンタックス変更がある場合、そもそも対応するコミットがgithubに無いっていう状況もありうるので、ちょっと明日確認させてください。

そもそも対応するコミットがgithubに無いっていう状況もありうる

ｗｗｗありがとうございます！

そうそう、clangも中のやつはossとは同じじゃないから的な話だった (edited)

Embedding SwiftSyntax in an Application

これにも挑戦してみます。

utils/build-parser-lib 、ビルドできなかった。 $ utils/update-checkout --tag swift-5.4-RELEASE 環境でも駄目だった。 https://gist.github.com/omochi/cb9d4595761759df0355069cb9481d12 swift compiler自体はmainブランチでビルドできたのだけど・・・

swift-syntax-lib-build-log.md

GitHub Gist: instantly share code, notes, and snippets.

チェックアウトしてるLLVMのバージョン違いっぽいエラーですけど、update-checkout後だとするとよくわかんないな

update-checkout succeeded cmake : skip cmark : 9c8096a23f44794bde297452d87c455fc4f76d42 icu : skip indexstore-db : bd2cf9468e5f81a65419c4b62da1663df83ebdb7 llbuild : eb56a00ed9dfd62c2ce4ec86183ff0bc0afda997 llvm-project : 439a44695a0534a26557cc34b4fe650dccb46aed ninja : e72d1d581c945c158ed68d9bc48911063022a2c6 sourcekit-lsp : 3df647c2f7d598b5dbad78a7c9c2f54fdbaf06dd swift : 3e4fab9bb6a56fc30d43e72eaff5b096cf160c55 swift-argument-parser : 986d191f94cec88f6350056da59c2e59e83d1229 swift-corelibs-foundation : b8c9b25e0bb50f4118f5bd9e53c14a8fa3fcf240 swift-corelibs-libdispatch : f13ea5dcc055e5d2d7c02e90d8c9907ca9dc72e1 swift-corelibs-xctest : 8ad2cec16133618af8d5da34bced263f44ac1159 swift-driver : 93e8b927225a62b963ebe13ab11e04192fa8a67b swift-format : fc3fab6bf6541e611830b122711af0bd750dec6f swift-integration-tests : 169ede0a8f440162042dd20c9912a20d74053296 swift-stress-tester : a4ca36e9c447b4a7cc7626b8b95e71e92236f0f9 swift-syntax : ce9020568227504e792d07839b91c5de18ed291a swift-tools-support-core : e95add83fc1042a0a0e260d342f9fc5608df9a84 swift-xcode-playground-support : 8f471406a4ffead2e734693ddb58b433e92ae3e1 swiftpm : 7cd58d6cc1945b14db1346792b39af609ce17fe9 yams : 51ef46468fda5a0fa1a201b8843791d0149d3c01 [omochi@omochi-iMacPro swift ((swift-5.4-RELEASE))]$ utils/build-parser-lib --release --no-assertions --build-dir ../temp

3:16 PM

update-checkoutはちゃんと動いた感じがある

The dependency target "clang-resource-headers" of target "swift-frontend"

clang-resource-headersってLLVM側のターゲットなんですけど、これが見つからないっていうのはやっぱりLLVMのチェックアウトがおかしそう

ログには３つあって、mainと5.4.1と5.4なのだけど、そのターゲットのエラーが出たのはmainだけだった

じゃあなんか最近変わったのかな

5.4と5.4.1は Undefined symbols for architecture x86_64: "clang::Decl::getOwningModuleSlow() const", referenced from:

手元で試してみよ

3:22 PM

チェックアウトされたリビジョンにはちゃんとgetOwningModuleSlowあった https://github.com/apple/llvm-project/blob/439a44695a0534a26557cc34b4fe650dccb46aed/clang/lib/AST/DeclBase.cpp#L114

Module *Decl::getOwningModuleSlow() const

こっちもあるな。

3:26 PM

clangって root/llvm-project/.../clang なんだっけ。 root/clang も存在してるんだけどそれがまずいのかな。

3:28 PM

[omochi@omochi-iMacPro swift-source]$ rm -rf clang clan [omochi@omochi-iMacPro swift-source]$ rm -rf clang [omochi@omochi-iMacPro swift-source]$ rm -rf clang-tools-extra/ [omochi@omochi-iMacPro swift-source]$ rm -rf compiler-rt/ [omochi@omochi-iMacPro swift-source]$ rm -rf lldb [omochi@omochi-iMacPro swift-source]$ rm -rf llvm [omochi@omochi-iMacPro swift-source]$ rm -rf swift-crypto

symlinkになってればOK

青いので実体ぽかった

じゃあそれが古かったのかな

3:29 PM

あー、消しちゃったから古かったか確認できないw

update-checkoutしてもsymlinkは生成されないようだけど、それは正しい？ (edited)

あれ、されないですか？

3:30 PM

--cloneつけてみたら作られるのかな

3:30 PM

特に自分で手動で作った記憶はないです

--cloneでも作られないな

3:34 PM

とりあえず消してやり直してみます

かなり昔にsymlink作るのやめてたっぽい https://github.com/apple/swift/pull/28305

なるほど。

そうすると古い疑いのあったroot/clangが使われることも無さそうだけどなぁ

Undefined symbols for architecture x86_64: "clang::Decl::getOwningModuleSlow() const", referenced from:

3:54 PM

同じだなあ。うーむ

一応，llvm-project のディレクトリでブランチ確認してみて下さい

[omochi@omochi-iMacPro swift ((swift-5.4-RELEASE))]$ cd .. [omochi@omochi-iMacPro swift-source]$ cd llvm-project/ [omochi@omochi-iMacPro llvm-project ((swift-5.4-DEVELOPMENT-SNAPSHOT-2021-04-23-a) %)]$ git status HEAD detached at swift-5.4-RELEASE Untracked files: (use "git add <file>..." to include in what will be committed) swift nothing added to commit but untracked files present (use "git add" to track)

4:01 PM

lrwxr-xr-x 1 omochi staff 37 6 9 23:55 swift -> /Users/omochi/work/swift-source/swift

4:01 PM

なんか余計なゴミが一個あったけどチェックアウトはされてた。

ふむ、swift-5.4-RELEASE か、試したことないや。main でもだめってことです？

あ、逆にmainは試してないですね、やってみます。mainはターゲットのエラーだったから、それは解消するかもしれないな。

[omochi@omochi-iMacPro install]$ tree . └── Applications └── Xcode.app └── Contents └── Developer └── Toolchains └── XcodeDefault.xctoolchain └── usr └── lib └── swift ├── _InternalSwiftSyntaxParser │   ├── SwiftSyntaxParser.h │   └── module.modulemap └── macosx └── lib_InternalSwiftSyntaxParser.dylib

4:15 PM

ビルドできました！

1

4:17 PM

ただよく考えたら、 SwiftSyntaxの Xcode 12.5 swift-5.4-RELEASE 0.50400.0 を使っているなら、 Xcode12.5に同梱されてる lib_InternalSwiftSyntaxParser を使えばいいですよね。 (edited)

あれ、SwiftSyntax自体をビルドしたいって話じゃなかったんでしたっけ

えーっと、やりたいことはXcode13betaでも12.5でも開発作業をしたいということなので

4:19 PM

1. Xcode13beta環境で、SwiftSyntaxをXcode13betaに対応するコミットに切り替える

4:19 PM

が一つの解決策だと思っててそれは質問してましたが、

4:19 PM

2. Xcode13beta環境でも、SwiftSyntaxのソースと、実行時のInternalSwiftSyntaxParserを12.5に合わせるでも良いよなあと。

4:20 PM

で、1でも2でも自分で InternalSwiftSyntaxParserをビルドする必要は無い気が今してきました。

なるほど。そうですね、InternalSwiftSytaxParserはXcodeのやつを使えばよさそう

4:21 PM

あとはSwiftSyntaxのgybを5.4ブランチで展開するだけ？

Yuta Saito

あとはSwiftSyntaxのgybを5.4ブランチで展開するだけ？

それは、何？

4:22 PM

SwiftSyntaxリポジトリにはgybが展開済みのコードがコミットされてるよ。 (edited)

それって5.3向けじゃないですか？

4:24 PM

0.50400.0 は 5.4 向けでしょ。

あ、そうか、12.5に合わせたいのか。

Yuta Saito

あとはSwiftSyntaxのgybを5.4ブランチで展開するだけ？

これは13betaに合わせるために5.5の展開後gybが必要だよな、という意図でした。5.4って言ってるのは間違い

あー、RELEASE用じゃないコミットではgybが展開されていない？

そんな気がしてました

4:30 PM

あれ、でも普通にmainブランチでコミットされてるな。じゃあ問題ないのか

Yuta Saito

これは13betaに合わせるために5.5の展開後gybが必要だよな、という意図でした。5.4って言ってるのは間違い

これ必要だけど、apple/swiftのxcode13対応コミットがわからなくて困ったというのが最初の質問でした

4:32 PM

（gybの展開にswiftのソースが必要なので）

なるほど。

https://github.com/apple/swift-syntax/tree/main/Sources/SwiftSyntax/gyb_generated

4:34 PM

mainブランチでもgyb_generatedディレクトリの中身としてコミットされてるからgybの展開は必要無さそう。

自前で展開は必要ないけど、展開済みのもののうちどれを選択するべきかがありますね

そう。それは最大の問題。

4:36 PM

[omochi@omochi-iMacPro swift-syntax (main=)]$ swift build /Users/omochi/github/apple/swift-syntax/Sources/SwiftSyntax/RawSyntax.swift:120:45: error: value of type 'swiftparse_token_data_t' has no member 'range' let textSize = hasCustomText ? Int(data.range.length) : 0 ~~~~ ^~~~~ /Users/omochi/github/apple/swift-syntax/Sources/SwiftSyntax/RawSyntax.swift:157:34: error: value of type 'swiftparse_token_data_t' has no member 'range' let startOffset = Int(data.range.offset) ~~~~ ^~~~~ /Users/omochi/github/apple/swift-syntax/Sources/SwiftSyntax/RawSyntax.swift:158:29: error: value of type 'swiftparse_token_data_t' has no member 'range' let length = Int(data.range.length) ~~~~ ^~~~~ /Users/omochi/github/apple/swift-syntax/Sources/SwiftSyntax/RawSyntax.swift:161:41: error: referencing operator function '<=' on 'BinaryInteger' requires that 'SourceLength' conform to 'BinaryInteger' precondition(startOffset + length <= utf8.count) ^ Swift.BinaryInteger:1:11: note: where 'Self' = 'SourceLength' extension BinaryInteger { ^ /Users/omochi/github/apple/swift-syntax/Sources/SwiftSyntax/RawSyntax.swift:163:45: error: extra argument 'offsetBy' in call let end = utf8.index(begin, offsetBy: length) ^~~~~~ /Users/omochi/github/apple/swift-syntax/Sources/SwiftSyntax/RawSyntax.swift:893:41: error: value of type 'swiftparse_token_data_t' has no member 'range' byteLength = Int(cnode.token_data.range.length) ~~~~~~~~~~~~~~~~ ^~~~~ /Users/omochi/github/apple/swift-syntax/Sources/SwiftSyntax/SyntaxParser.swift:196:58: error: extra argument in call swiftparse_parse_string(c_parser, buf, source.utf8.count) ~~~~~~~~~~~~^~~~~ [41/44] Compiling SwiftSyntax SyntaxNodes.swift

4:36 PM

SwiftSyntax, mainブランチだとXcode12.5でビルドできない。

mainは5.5用のはず

Swift5.5でそんな非互換あったっけ。

これちゃんと読むとInternalSyntaxParserのヘッダの互換性の問題っぽい

asyncとか結構大きく増えたからかな？

そもそも5.5のソースをパースしたいんでしたっけ？

/Users/omochi/github/apple/swift-syntax/Sources/SwiftSyntax/RawSyntax.swift:120:45: error: value of type 'swiftparse_token_data_t' has no member 'range' let textSize = hasCustomText ? Int(data.range.length) : 0 ~~~~ ^~~~~

パースしたいソースは5.4互換ですね (edited)

@_implementationOnly import _InternalSwiftSyntaxParser import Foundation typealias CSyntaxNode = swiftparse_syntax_node_t typealias CTriviaPiece = swiftparse_trivia_piece_t typealias CSyntaxNodePtr = UnsafePointer<CSyntaxNode> typealias CTriviaPiecePtr = UnsafePointer<CTriviaPiece> typealias CSyntaxKind = swiftparse_syntax_kind_t typealias CTokenKind = swiftparse_token_kind_t typealias CTriviaKind = swiftparse_trivia_kind_t typealias CTokenData = swiftparse_token_data_t typealias CLayoutData = swiftparse_layout_data_t typealias CParseLookupResult = swiftparse_lookup_result_t typealias CClientNode = swiftparse_client_node_t typealias CDiagnostic = swiftparser_diagnostic_t typealias CFixit = swiftparse_diagnostic_fixit_t typealias CRange = swiftparse_range_t

4:39 PM

あーここで、 InternalSwiftSyntaxParser に依存しているのか。

4:40 PM

Swift5.4で Swift5.3向けのSwiftSyntaxがビルドできたのはたまたまで

4:40 PM

Swift5.5向けのSwiftSyntaxは、5.4と5.5の間に、 InternalSwiftSyntaxParserの提供するC structのメンバ定義に変化があり

4:41 PM

Swift5.4同梱のInternalSwiftSyntaxParser環境ではSwiftSyntaxがコンパイルできないみたい。

そうそう、僕はそう思ってます

This preserves the property that SwiftSyntax is a self-contained Swift module

https://github.com/apple/swift-syntax/tree/main/Sources/_CSwiftSyntax

4:41 PM

これは嘘だったのか。

_CSwiftSyntaxはまた別です

4:42 PM

これはatomic周りのSwiftで書けない機能を提供するモジュールだったはず。InternalSwiftSyntaxParserとは無関係

うーんとじゃあ

2. Xcode13beta環境でも、SwiftSyntaxのソースと、実行時のInternalSwiftSyntaxParserを12.5に合わせる

これはやっぱり無理なのか。

いや、できるんじゃないですか？

4:45 PM

普通に12.5のInternalSwiftSyntaxParserのmodule.modulemapが優先して見られるようにinclude optionを付けたら良いと思います

実行時だけじゃなくて、コンパイル時も、Xcode12.5同梱のInternalSwiftSyntaxParserを使うようにしないといけない。

Xcode13beta環境でも、っていうのはSwiftSyntaxを使うツールを13betaで開発したいって話ですか？

いや、いやいや、無理じゃないか？

4:46 PM

いや、いけるのか

Yuta Saito

Xcode13beta環境でも、っていうのはSwiftSyntaxを使うツールを13betaで開発したいって話ですか？

そう

4:47 PM

Swift5.4のソースコードを処理するツールを開発・実行したいその作業はXcode12.5でも13betaでもやりたい。

4:48 PM

Xcode13で普通にビルドする限りXcode13が同梱してる ISSP もサーチパスに入っちゃうけど

4:48 PM

どこで指定すれば優先してXcode12.5版を発見するようになるんだろう？

generate-xcodeprojがありならoverride-xcconfigでHEADER_SEARH_PATHを上書きするか

それは無しかなあ

4:51 PM

SwiftPM for Xcode だと、schemeでいじれるのは実行時オプションだけで、コンパイルオプションはさわれないのか。

4:51 PM

.unsafeFlags を指定するのは、 SwiftSyntaxのPackage.swiftにないと駄目だな。

そうそう

(この前さの先生がやってたやつだ）

4:53 PM

$ swift build だったら -Xswiftc か -Xcc あたりかな。ちゃんと優先されるんだろうか

4:54 PM

SwiftSyntaxをチェックアウトしてきて、editモードでプロジェクトにオーバライドして、

4:54 PM

SwiftSyntaxのPackage.swiftを書き換えてunsafeFlagsを注入するのがマシかなー (edited)

ローカルの状況への依存強くて厳しいなぁ

そうだねえ

SwiftSyntax自体の開発中にどうしてるのか気になる

4:56 PM

この状況と同じなきがする

SwiftSyntaxをビルドして、バイナリ配布するパッケージを自分で作ってしまって、

4:57 PM

プロジェクトからはそっちを使うようにしたら、全部解決するか？

4:59 PM

XCFrameworkってdylibも詰め込んでおけるのかな

できるできる

5:00 PM

ただそうするとバイナリの配布が1ファイルじゃなくなるのでちょっと面倒くさい

5:01 PM

InternalSwiftSyntaxParserを一緒に配布するならそもそも1ファイルじゃ済まないので変わらないですけど

世の中的には

5:04 PM

SwiftSyntaxと、ISSP両方が一発でバイナリ配布されてると嬉しいのでは。

そう思います…

とりあえずxcodeproject作ってみるか

ISSPはツールチェーンから切り離して配布してほしい気持ちがある

.framework の中にライブラリ自体とそれは別に依存する他のdylibをポン置きできるんだっけ。

@loader_pathからの相対でrpathを指定するとそういうことが出来たはず

あー install_name_tool で隣見るようにしてやればいいのか

たしかそんな感じだったはず。

5:10 PM

なんかおもちさんのQiitaの記事見た記憶がある

↑コマンド名思い出せなかったからググって自分の記事見てきた。

w

<unknown>:0: error: module map file '/Users/omochi/github/omochi/BinarySwiftSyntax/build/GeneratedModuleMaps/_CSwiftSyntax.modulemap' not found <unknown>:0: error: module map file '/Users/omochi/github/omochi/BinarySwiftSyntax/build/GeneratedModuleMaps/_CSwiftSyntax.modulemap' not found <unknown>:0: error: missing required module 'SwiftShims'

5:21 PM

うーん？

なんだっけ、sysrootに入れないとSwiftShimsが見えないんだっけな

Xcodeの機能でSwiftSyntaxを依存に入れただけなんだけど

5:24 PM

なぜかarchiveできない

5:25 PM

https://github.com/omochi/BuildBinarySwiftSyntax

omochi/BuildBinarySwiftSyntax

Contribute to omochi/BuildBinarySwiftSyntax development by creating an account on GitHub.

5:26 PM

xcodeproj開いて普通にCmd + Bでのビルドは通る

アーカイブのコンパイルコマンドとビルドのコンパイルコマンドを見比べるくらいしか出来ることなさそう

難しくなってきた

5:30 PM

archiveモードの方が余計なパスが渡らない挙動になってそうだなー

5:36 PM

前から思ってるんだけど、

5:36 PM

コンパイラに渡してる引数をいい感じに配慮してdiff取ってくれるやつほしいよね。

毎回 vim で整形してソートして…ってやってる

XcodeProjのSwiftPM dependencyだとビルドオプションの調整などが難しいし、ソースを直接XcodeProjに登録してシンプルなビルドにしてやってみるか。また後で。

omochimetaru

そもそも対応するコミットがgithubに無いっていう状況もありうる

ｗｗｗありがとうございます！

まだ確実な回答得られてないのですが、力業としては

# strings /path/to/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/lib_InternalSwiftSyntaxParser.dylib | grep -E '[a-f0-9]{32}' 4f85168b3860f575ce60ac0d223fc89da37014df # cd swift-syntax # git log -S 4f85168b3860f575ce60ac0d223fc89da37014df

とかで割り出すっていう笑

rintaro

まだ確実な回答得られてないのですが、力業としては

# strings /path/to/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/lib_InternalSwiftSyntaxParser.dylib | grep -E '[a-f0-9]{32}' 4f85168b3860f575ce60ac0d223fc89da37014df # cd swift-syntax # git log -S 4f85168b3860f575ce60ac0d223fc89da37014df

とかで割り出すっていう笑

あ、そうか、バイナリの中にコミットハッシュが入ってるんだから、それを読んじゃえばいいのか。

5:03 AM

後でやってみます！

コミットハッシュというか、gybのダイジェストですね。 https://github.com/apple/swift-syntax/blob/18880228fa4de8c3368d66ead6f4e0dfd4c7f1f9/Sources/SwiftSyntax/gyb_generated/Misc.swift#L1963

なるほど。

5:08 AM

そこはSwiftSyntax側だとソース内に書いてあるから git log -S で変更履歴達が出てくるんですね。 (edited)

です。現れたコミットと、消されたコミットが出てくるはず。（githubに存在すれば）

commit 1d0a2c1bd249daffd35a340e9482060121667f21 Author: Rintaro Ishizaki <rishizaki@apple.com> Date: Thu Apr 29 09:15:06 2021 -0700 Update for postfix '#if' expression diff --git a/Sources/SwiftSyntax/gyb_generated/Misc.swift b/Sources/SwiftSyntax/gyb_generated/Misc.swift index cc8ace1..73841bd 100644 --- a/Sources/SwiftSyntax/gyb_generated/Misc.swift +++ b/Sources/SwiftSyntax/gyb_generated/Misc.swift @@ -471,6 +471,12 @@ extension SyntaxNode { return ObjcSelectorExprSyntax(asSyntaxData) } + public var isPostfixIfConfigExpr: Bool { return raw.kind == .postfixIfConfigExpr } + public var asPostfixIfConfigExpr: PostfixIfConfigExprSyntax? { + guard isPostfixIfConfigExpr else { return nil } + return PostfixIfConfigExprSyntax(asSyntaxData) + } + public var isEditorPlaceholderExpr: Bool { return raw.kind == .editorPlaceholderExpr } public var asEditorPlaceholderExpr: EditorPlaceholderExprSyntax? { guard isEditorPlaceholderExpr else { return nil } @@ -1621,6 +1627,8 @@ extension Syntax { return node case .objcSelectorExpr(let node): return node + case .postfixIfConfigExpr(let node): + return node case .editorPlaceholderExpr(let node): return node case .objectLiteralExpr(let node): @@ -1952,6 +1960,6 @@ extension Syntax { extension SyntaxParser { static func verifyNodeDeclarationHash() -> Bool { return String(cString: swiftparse_syntax_structure_versioning_identifier()!) == - "468bcd348ceb5f9281692e63d4c80e3333a18211" + "4f85168b3860f575ce60ac0d223fc89da37014df" } }

5:41 AM

@rintaro りんたろーさんのコミットが出てきたｗ

5:42 AM

SE-0308 の対応のやつだ

ですねー。それのマージコミットあたりであれば動くと思います。

@rintaro 動きました！ありがとうございます！ (edited)

1

https://github.com/omochi/SwiftTypeReader/pull/3/files

7:10 AM

SwiftSyntaxをビルド環境に応じて切り替える仕組みでとりあえずの目的は果たしたが

7:10 AM

ルートプロジェクトのPackage.resolvedで編集合戦が生じる事に気がついて

7:10 AM

やっぱりバイナリ配布を目指したくなった。 (edited)

SwiftSyntax.xcframework できた！動いた！

はやい

コードサインからワイの名前が漏れてる

https://github.com/omochi/BinarySwiftSyntax

omochi/BinarySwiftSyntax

Contribute to omochi/BinarySwiftSyntax development by creating an account on GitHub.

5:06 PM

いろいろよくわからなかったので愚直にやった。

メールアドレスも

メルアドはどうせコミットメッセージに漏れてる

w

5:08 PM

使い分けがあったらうっかりとかあるよなあ

よくわからないけどフレームワークは別にサインする必要ないんじゃないの？サインするのは使う人がやればいいから。

そうなんすか？ $ xcodebuild archive... したら、勝手にされちゃった。

なるほど。 CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO CODE_SIGNING_ALLOWED=NO こんなパラメータをつけるとOKだと思う。

やってみます。

お、ほんとうだ、コードサインに関する生成物が消えましたが普通にバイナリは出てきました

5:24 PM

利用側も普通に動きますね。ありがとうございます。

XcodeでいうとEmbed&Signってのがフレームワークに署名するやつですね。

5:25 PM

使う人が。

5:26 PM

フレームワークの署名はしてもどうせ上書きされるんですよ。

あそこで最終的な出荷者が全部署名しなおすのが基本なんですね。

5:27 PM

force pushしてなかったことにした。

1

なかったことになった

1

さすがにSwiftSyntaxのXCFrameworkはMac用しか出ないですか？しれっとiPad用とかビルドできたりしないかな。

https://github.com/apple/swift-syntax#embedding-in-an-ios-application

apple/swift-syntax

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

5:46 PM

Embedding in an iOS Application

5:46 PM

これにしがって、 libInternalSyntaxSwiftParser.dylib のiOS用のものを作れば対応できるようです。

あ、いけるのか。すごい。

今僕のBinarySwiftSyntaxは、SwiftSyntax部分のパッケージ化だけをやっていて、libISSP.dylibは自分でxcodeのを実行時リンクしてねというところまでしかやってないので、

じゃあSyntaxまでならiOSでParseできるのか。

ですね。

5:47 PM

今の状態だとiOSは追加できないけど、 mac向けにlibISSPを同梱してしまいたいとは思っていて

5:48 PM

そこまでやるんだったらiOS版もlibISSPとビルドしたframeworkを用意してxcframeworkに突っ込む事ができなくもないですね。

どうもどうも。興味深いですね。

iPadのswiftplaygroundでアプリ作れるやつが出たから、

5:50 PM

iOS上でのコード編集とかも広がるんかなあ？

libISSP.dylib for iOS、Swift Playgrounds のIPAから抜いて来れないかな？と思ったけど、FairPlayかかってるから厳しいか…

たしかに。理論上そこに入ってるはずですね。 FairPlayってなんですか？

AppleのDRMの名称で、iOS App Store で落としたAppの実行可能バイナリとか、Apple Music (!= iTunes Store) でダウンロードしてきた音声ファイルとか iBooks で買った電子書籍とかはもれなくこれで暗号化されてます

なるほど

ipaはFairplayかからなくなってるんじゃないかな。だいぶ前から。

6:30 PM

今でもかかってましたっけ？

Load command 26 cmd LC_RPATH cmdsize 40 path @loader_path/Frameworks (offset 12) [omochi@omochi-iMacPro A (main *+%=)]$ otool -L SwiftSyntax SwiftSyntax: @rpath/SwiftSyntax.framework/Versions/A/SwiftSyntax (compatibility version 1.0.0, current version 1.0.0) @rpath/lib_InternalSwiftSyntaxParser.dylib (compatibility version 1.0.0, current version 18010.0.0) ... [omochi@omochi-iMacPro A (main *+%=)]$ ls Frameworks Headers Modules Resources SwiftSyntax [omochi@omochi-iMacPro A (main *+%=)]$ ls Frameworks _CSwiftSyntax.framework lib_InternalSwiftSyntaxParser.dylib

(edited)

3:19 PM

なんかXcodeProjに突っ込んだら普通にできた感じがするな (edited)

RPATH failed expanding @rpath/lib_InternalSwiftSyntaxParser.dylib to: /usr/lib/swift/lib_InternalSwiftSyntaxParser.dylib RPATH failed expanding @rpath/lib_InternalSwiftSyntaxParser.dylib to: /Applications/Xcode12.5.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Xcode/Agents/../Frameworks/lib_InternalSwiftSyntaxParser.dylib dyld: loaded: <3D321011-1279-30C7-A9AE-FF13073508AD> /Users/omochi/Library/Developer/Xcode/DerivedData/SwiftTypeReader-eqfhomccxzrdaphbladexpydmlbp/Build/Products/Debug/SwiftSyntax.framework/Versions/A/Frameworks/lib_InternalSwiftSyntaxParser.dylib RPATH successful expansion of @rpath/lib_InternalSwiftSyntaxParser.dylib to: /Users/omochi/Library/Developer/Xcode/DerivedData/SwiftTypeReader-eqfhomccxzrdaphbladexpydmlbp/Build/Products/Debug/SwiftSyntax.framework/Versions/A/Frameworks/lib_InternalSwiftSyntaxParser.dylib

3:32 PM

できたできた

3:35 PM

dyld: loaded: <3D321011-1279-30C7-A9AE-FF13073508AD> /Users/omochi/github/omochi/SwiftTypeReader/.build/x86_64-apple-macosx/debug/SwiftSyntax.framework/Versions/A/Frameworks/lib_InternalSwiftSyntaxParser.dylib

3:35 PM

xcodeとswift-cli両方いけた

SwiftSyntaxParserTest/ClassificationTests.swift:9: Fatal error: 'try!' expression unexpectedly raised an error: The loaded '_InternalSwiftSyntaxParser' library is from a toolchain that is not compatible with this version of SwiftSyntax

むむむ

5:35 AM

あ、わかった

5:37 AM

[omochi@omochi-iMacPro Toolchains]$ ls -alh total 0 drwxr-xr-x 6 root wheel 192B 8 23 14:28 . drwxr-xr-x 6 root admin 192B 6 6 2021 .. drwxr-xr-x 7 root wheel 224B 8 2 19:13 swift-5.7-DEVELOPMENT-SNAPSHOT-2022-07-23-a.xctoolchain drwxr-xr-x 7 root wheel 224B 5 19 15:40 swift-DEVELOPMENT-SNAPSHOT-2022-05-18-a.xctoolchain drwxr-xr-x 7 root wheel 224B 8 23 14:28 swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain lrwxr-xr-x 1 root wheel 81B 8 23 14:28 swift-latest.xctoolchain -> /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain [omochi@omochi-iMacPro Toolchains]$ export TOOLCHAINS=swift [omochi@omochi-iMacPro Toolchains]$ xcrun -find swift /Library/Developer/Toolchains/swift-5.7-DEVELOPMENT-SNAPSHOT-2022-07-23-a.xctoolchain/usr/bin/swift

5:37 AM

TOOLCHAINS=swift が選択するやつが思ったのと違ったわ

5:41 AM

あれ、最新スナップショットの08-18でも駄目だな・・・？

18日に変更されているので、今は自前でビルドしないとだめかもしれませんね。 https://github.com/apple/swift/commits/main/utils/gyb_syntax_support (edited)

5:47 AM

ここか〜

5:49 AM

[omochi@omochi-iMacPro swift]$ swift/utils/build-tooling-libs --release --no-assertions --build-dir temp/tooling-libs-build

これ使うの初めてだ

5:54 AM

-- Using Experimental String Processing library for libswift _RegexParser (/Users/omochi/github/apple/swift/swift-experimental-string-processing). CMake Error at /Users/omochi/github/apple/swift/swift/SwiftCompilerSources/CMakeLists.txt:274 (message): Outdated Swift compiler: building with host tools requires Swift 5.8 or newer. Please update your Swift toolchain or switch BOOTSTRAPPING_MODE to BOOTSTRAPPING(-WITH-HOSTLIBS)? or OFF. -- Configuring incomplete, errors occurred! See also "/Users/omochi/github/apple/swift/temp/tooling-libs-build/x86_64/obj/CMakeFiles/CMakeOutput.log". See also "/Users/omochi/github/apple/swift/temp/tooling-libs-build/x86_64/obj/CMakeFiles/CMakeError.log". ERROR: command terminated with a non-zero exit status 1, aborting

これでたけど

[omochi@omochi-iMacPro swift]$ swift/utils/build-tooling-libs --release --no-assertions --build-dir temp/tooling-libs-build --swiftc /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/bin/swiftc

これでいけた

5:54 AM

build-tooling-libs は TOOLCHAINS は見ないのだな・・・

6:00 AM

@rintaro 自前でビルドしたらswift-syntaxのswift test実行できました

6:06 AM

[omochi@omochi-iMacPro swift-syntax (main=)]$ swift test --filter SwiftParserTest.* Building for debugging... Build complete! (0.25s) error: signalled(6): /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/libexec/swift/pm/swiftpm-xctest-helper /Users/omochi/github/apple/swift-syntax/.build/x86_64-apple-macosx/debug/SwiftSyntaxPackageTests.xctest /var/folders/1v/_s33fkpj07g9y3zvdfs9cz9m0000gn/T/TemporaryFile.G8m0Jq output: dyld[59495]: Library not loaded: @rpath/XCTest.framework/Versions/A/XCTest Referenced from: /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/libexec/swift/pm/swiftpm-xctest-helper Reason: tried: '/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/libexec/swift/pm/../lib/XCTest.framework/Versions/A/XCTest' (no such file), '/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/libexec/swift/pm/../../../lib/swift/macosx/XCTest.framework/Versions/A/XCTest' (no such file), '/usr/lib/swift/XCTest.framework/Versions/A/XCTest' (no such file), '/Users/ec2-user/jenkins/workspace/oss-swift-package-macos/build/buildbot_osx/intermediate-install/macosx-x86_64/Applications/Xcode.app/Contents/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/lib/swift/macosx/../../swift-5.5/macosx/XCTest.framework/Versions/A/XCTest' (no such file), '/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/libexec/swift/pm/../lib/swift/macosx/XCTest.framework/Versions/A/XCTest' (no such file), '/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/libexec/swift/pm/../lib/XCTest.framework/Versions/A/XCTest' (no such file), '/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/libexec/swift/pm/../../../lib/swift/macosx/XCTest.framework/Versions/A/XCTest' (no such file), '/usr/lib/swift/XCTest.framework/Versions/A/XCTest' (no such file), '/Users/ec2-user/jenkins/workspace/oss-swift-package-macos/build/buildbot_osx/intermediate-install/macosx-x86_64/Applications/Xcode.app/Contents/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/lib/swift/macosx/../../swift-5.5/macosx/XCTest.framework/Versions/A/XCTest' (no such file), '/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/libexec/swift/pm/../lib/swift/macosx/XCTest.framework/Versions/A/XCTest' (no such file), '/System/Library/Frameworks/XCTest.framework/Versions/A/XCTest' (no such file)

--filter するとだめになった・・・

XCTest が読めない

https://github.com/apple/swift/issues/55583

[SR-13136] swift test --filter doesn't work in snapshot · Issue #55...

Previous ID SR-13136 Radar None Original Reporter cukier (JIRA User) Type Bug Environment macos 10.15.4 (19E287) swift-DEVELOPMENT-SNAPSHOT-2020-07-01-a.xctoolchain Additional Detail from JIRA Vote...

6:07 AM

似てる

6:08 AM

[omochi@omochi-iMacPro swift-syntax (main=)]$ xcrun -find XCTest /Applications/Xcode14.beta.5.app/Contents/Developer/usr/bin/XCTest [omochi@omochi-iMacPro swift-syntax (main=)]$ xcrun -find swift /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/bin/swift

6:08 AM

う〜む？

XCTestがスナップショットツールチェインに無い？

[omochi@omochi-iMacPro swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain]$ find . | grep XCTest なさそう

6:09 AM

でも swift test なら通るんだよね、そもそも。

6:10 AM

swift test --filter foo するとXCTestが見つからなくなる

6:12 AM

'/Users/ec2-user/jenkins/workspace/oss-swift-package-macos/build/buildbot_osx/intermediate-install/macosx-x86_64/Applications/Xcode.app/Contents/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/lib/swift/macosx/../../swift-5.5/macosx/XCTest.framework/Versions/A/XCTest' (no such file),

6:12 AM

Xcodeの中を探すところがjenkinsになってるｗ

filterするときにテストケースの一覧が必要で、それを取得するためのツールにswiftpm-xctest-helperがあるんですけど、それがXCTestをリンクしてるのか

あ、そういうことか。

6:13 AM

filterの前処理のためのツールなのか。

swift test単体だとSwiftPMがxcrunで探してきてくれたXCTestをリンクしたテストバンドルをxctestコマンドで実行するだけなのでOK

6:15 AM

だからswiftpm-xctest-helperも実行時にSwiftPMが探してきたXCTestをロードするようにするべき？

$ export DYLD_LIBRARY_PATH=/Applications/Xcode14.beta.5.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks

これは駄目だった

6:24 AM

Xcodeの中から /Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2022-08-18-a.xctoolchain/usr/lib/swift/macosx/ にいろいろコピペしたらとりあえず動いた

XCTest.framework XCTestCore.framework XCTestSupport.framework XCUIAutomation.framework XCUnit.framework linXCTestSwiftSupport.dylib

(edited)

 mutating func advanceIfMultilineDelimiter(_ CustomDelimiterLen: Int, _ IsOpening: Bool = false) -> Bool { // Test for single-line string literals that resemble multiline delimiter. var TmpPtr = self _ = TmpPtr.advance()

LLVM C++ StyleなSwiftコードだ

1

https://github.com/apple/swift-syntax/issues/618

SwiftParser crashes on string with nested interpolation · Issue #61...

The parser is crashing on a string literal with nested interpolation. Found by running verify-round-trip on the source code for swift-argument-parser. Reproduced with 38e3e4d. $ cat str.swift &...

5:42 AM

これ直せないかチャレンジしてる

5:43 AM

やっぱCMake/C++と違ってSwiftPMで普通にXcodeからデバッガ動くのは便利だ

https://github.com/apple/swift-syntax/pull/619/files

7:43 AM

Doug先生のこのPR面白い

7:43 AM

var opPrecedence = OperatorPrecedence.standardOperators // Use the Swift standard library operators let parsed = try Parser.parse(source: "x + y * z") dump(parsed) // contains SequenceExprSyntax(x, +, y, *, z) let folded = try opPrecedence.foldAll(parsed) dump(folded) // contains InfixOperatorExpr(x, +, InfixOperatorExpr(y, *, z))

7:43 AM

SwiftSyntaxのASTを、演算子優先度を解釈したASTに変換する

7:44 AM

let parsedOperators = try Parser.parse(source: moreOperators) // Adds **, ExponentiationPrecedence to the set of known operators and precedence groups. try opPrecedence.addSourceFile(parsedOperators) let parsed2 = try Parser.parse(source: "b ** c ** d") dump(parsed2) // contains SequenceExprSyntax(b, **, c, **, d) let folded2 = try opPrecedence.foldAll(parsed2) dump(folded2) // contains InfixOperatorExpr(b, **, InfixOperatorExpr(c, **, d))

7:44 AM

さらに、演算子定義を含むソースコードのASTを突っ込んでやると、それを解読して演算子優先度定義を更新して、その定義でAST変換する

7:46 AM

セマンティックな操作だけど、アウトプットとしてAST木の書き換えとして作業が完了するタスクだから、SwiftSyntaxのおまけライブラリとして完結できてる。

おもしろいねえ

SwiftSyntaxのSwift Parserに """" を食わせると、１文字目と５文字目に " が足りませんよ、っていう出力になるんだが """""" は別に正しいコードになってないので謎だ。

4:21 AM

[omochi@omochi-iMacPro swift-syntax (add-fixed-issues-test %=)]$ .build/debug/swift-parser-test dump-tree crash.swift SourceFileSyntax children=2 0: CodeBlockItemListSyntax children=1 0: CodeBlockItemSyntax children=1 0: StringLiteralExprSyntax children=3 0: stringQuote MISSING 1: StringLiteralSegmentsSyntax children=1 0: StringSegmentSyntax children=1 0: stringSegment("\"\"\"\"") 2: stringQuote MISSING 1: eof

4:23 AM

パース結果としてはこうなってるんだけど、「ダブルクォート4個のstring segment」が一つだけの文字列になっているのも謎だ。ダブルクォートが文字列のコンテンツになっちゃった。そして文字列を包むダブルクォートは両端で消失。

4:24 AM

実装を追って調べてみようと思う。

Lexerではトリプルクォートのオープン＋内容がダブルクォート１文字（改行が無い不正を無視、クローズクォート行方不明）として処理され、結果的にクワドラクォートのstring literal token になり

6:41 AM

Parserではstring literal tokenの再解釈で異なるロジックになり、

6:41 AM

さらにParser内部でも、オープンクォートのパース時には " + "" + " に解釈しようとしかけるが、(ダブルクォート2つがコンテンツである文字列) (edited)

6:43 AM

後段の処理はそのつもりが無くてダブルクォート4つの文字列、オープナーが無いので空文字列で挟まれている、とされ、

6:43 AM

Tokenの汎用処理でゼロ長トークンが missing 扱いされる

6:43 AM

って感じで壮大に混乱しながら処理が進行してたｗ

めっちゃ迷子になってるｗ

あ、ちょっと違うな、 " + "" + " のロジックは # がついてる時だけだ。

Doug先生が怒涛のバグ出ししててウケた

https://twitter.com/dgregor79/status/1564862291707052033

Doug Gregor (@dgregor79)

I love when a bit of testing infrastructure instantly provides a giant leap forward in test coverage. With my latest hack, we can piggyback the new Swift parser on the real Swift compiler, looking for crashes and input source round-trip failures in everything we build.

9:14 PM

このツイートで言及されている "my latest hack" は https://github.com/apple/swift/pull/60888 です

Optional support for round-trip testing the new Swift parser. by Do...

When enabled, compile in support for round-trip testing the new SwiftSyntax-provided Swift parser alongside the existing parser. Right now, this means parsing every source file with the new parser ...

おお、そういうことか！

2:30 AM

早速繋げてみたことでいろんな入力叩き込んでバグがみつけられたのね

ParseSourceFileRequest::evaluate に swift_parser_consistencyCheck とやらを仕込んだ

private(set) のパースを考えるときに private(var という入力が来たら、 private(set) var の set) がスッポ抜けていると考えるという動作が parser.expect(.rightParen) だとできるなあ (edited)

でも private(get, set) を考えると、, が ) より強いので、 get, をノイズと判定できずに , で力尽きて set) の不存在と、後続ノイズの set) になってしまうな。

https://github.com/apple/swift-syntax/pull/704#discussion_r962583292 英会話難しい

7:46 AM

expect 使ったら？というコメントが来たので、それだと private(get, set) のパースが微妙になってしまう、という返事をしたけど、もしいろいろ誤読してるとややこしくなりそうなので実装例も用意して説明をした (edited)

7:47 AM

extra token munging here. はおそらく先行する２つのwhile loopとかを言ってるんだと思うけど、もしかしたらただ consume(if:) の1行だけを指してるのかもしれない・・・

https://github.com/apple/swift-syntax/pull/707 ↑ワイの困りについて書いたら、token precedence自体に改修が入りそう。これだと ) を探すときに get も , も食えるから助かるな。 openとcloseでレベルが違う事になってるけどそれは問題ないんだろうか

expectで ) まで走るのは求めてるのとちょっと違うな。探してるものが見つからずに強いトークンにぶつかった場合、先読み失敗じゃなくてそこで止まってほしいわ

expectシステムがめっちゃ改良された・・・

1

4:33 AM

あーすげえ declaration のパースロジックがめっちゃ先読みベースに変わってる

https://github.com/apple/swift-syntax/pull/704 長い戦いだった

Improve parsing of access level modifier by omochi · Pull Request #...

This PR fix #631. It can round-trip correctly without crashing. Not only that, I tried to improve recovering logic here. For example, the logic recover such wrong inputs intuitively way. private(ge...

4

7:09 AM

次にやろうと思ってた good first issues たちが軒並み解決しているｗ

7:13 AM

詳細追ったらちょこちょこコントリビューターが直してるのもあった。

7:15 AM

#704 のために導入してくれた canRecoverToContextualKeyword が他では一箇所も使われてないから、実装パターンを改善したり、壊れたコードに対する回復力を高められる場所がいろいろ眠ってそうな気はする

7:16 AM

まあ壊れたコード、別に書かないけど・・・入力途中で必然的に壊れてるときの補間とかが生きたり死んだりするんだろうなあ

#777

error: 'where' clause next to generic parameters is obsolete, must be written following the declaration's type

#778

'inout' before a parameter name is not allowed, place it before the parameter type instead

既存コンパイラだと特定の文法間違いに対して専用のエラーメッセージが出るのか。既存コンパイラはパーサがその場で直接diagnostics吐けるからそこそこ簡単に実装できるけど、これSwift Parser Syntaxだと間違った文法をいったんsyntax treeとして獲得してから、 treeに対する診断として出さないといけない(多分?)から、誤った文法を含めた文法を考えないといけなくて大変だ (edited)

https://github.com/apple/swift-syntax/pull/767

Recore deprecated SwiftSyntaxParser on top of SwiftParser. by DougG...

This drops the dependency on the _InternalSwiftSyntaxParser library, and the entire C++ parser/AST/libSyntax stack.

9:10 AM

SwiftParserへの切り替えPR

his drops the dependency on the _InternalSwiftSyntaxParser library, and the entire C++ parser/AST/libSyntax stack.

9:10 AM

思ったより早く来るのかもこれは嬉しいな　ISSPはよく困るので

swift-formatがSwiftParserで書き直されてる https://github.com/apple/swift-format/pull/395

Adopt the Swift Parser by CodaFi · Pull Request #395 · apple/swift-...

Adopt the new Swift parser in swift-format This would otherwise be a fairly straightfoward patchset, but there's some existing tests that are failing on mainline that I've gone ahead and in...

1

展開早いな

ガッとできる腕力がすごい

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

Drop libSyntax's Unit Tests by CodaFi · Pull Request #61123 · apple...

We no longer intend to support the libSyntax AST, so let's drop the tests that are only going to get in the way of us iterating on the Swift Syntax tree.

5:45 AM

展開早い

https://github.com/apple/swift-syntax/issues/816 appleのrdarのリンクの書き込みをよく分かってないんですが、社内のバグトラッカーに報告されているような認識であっているかご存知の方いらっしゃったら教えていただきたいです

if-let shorthand syntax is broken when formatting in 0.50700.0 · ...

Description In swift-format@0.50700.0, the unrecognized error is occured in SE-0345 syntax. It looks like it was addressed in #494 , is it not included in 0.50700.0? If this is not to ask here, ple...

そうですそうです。Apple社内のバグトラッカーに登録したっていう意味ですね。

1

ありがとうございます！OpenRadarとかを見に行くといいのかわからずちょっと調べていたので助かりました！

https://forums.swift.org/t/update-on-the-new-swift-parser/60470

Update on the new Swift Parser

Hi all, It's been a month since we introduced the new Swift parser into swift-syntax. Since then, we've made some great progress, so I wanted to share some of that here: The new parser is now linked into the compiler, with additional testing that we can enable for every single compile. There are two kinds of tests at the moment: Round-trip ...

5:18 PM

進捗報告

5:21 PM

swift-formatが切り替わったらしい

https://github.com/apple/swift-syntax/issues/860

Two divisions treated like regex literal · Issue #860 · apple/swift...

Issue Kind Parse of Valid Source Produced Invalid Syntax Tree Source Code UIColor(white: 216.0/255.0, alpha: 44.0/255.0) Description The Swift Parser thinks this is a regex literal: regexLiteral(&a...

4:42 AM

このバグは面白いw

4:42 AM

でもどういう規則で防止すればいいんだろ？

UIColor(white: 216.0/255.0, alpha: 44.0/255.0) // regexLiteral("/255.0, alpha: 44.0/") (edited)

Swift SyntaxのParserはいつの間にか引数が増えてSwiftバージョンを指定したりRegex LiteralのON/OFFができるようになってるんだな。

@Kishikawa Katsumi ここってIdentifierExprが出てこないのってなぜだかわかります？

すぐにはわからないですね。デバッグしてみないと。 ASTを歩くコードは最初に書いたときからほとんど変わってないので、SwiftSyntaxの変化についていけてなくて取りこぼしてるのかもしれない。

5:48 PM

でもそいつはIdentifierExprじゃないんじゃないの？

MemberAccessExprが foo.bar を表すんですけど、fooもbarもtokenとしてはidentifierで、 fooのほうはidentifier exprなんですが、barの方はそうじゃない(ただのtoken)、というsyntaxなのかなあ。

5:53 PM

よく考えてみるとfooのところは変数名とかも使えるけど、ドットの右のbarのところは、fooの型に応じたメンバしか書けないから、書けるものがより少ないから、別の概念なのかな。

5:58 PM

https://github.com/apple/swift-syntax/blob/95d3b69cadaee72bed96113596ee1d354cba93b8/Sources/SwiftSyntax/gyb_generated/syntax_nodes/SyntaxExprNodes.swift#L5410

swift-syntax/SyntaxExprNodes.swift at 95d3b69cadaee72bed96113596ee1...

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swift-syntax/SyntaxExprNodes.swift at 95d3b69cadaee72bed96113596ee1d354cba93b8 · apple/swift-syntax

5:58 PM

そうっぽい

そうなんだ。

baseはExprSyntaxで、nameはTokenSyntaxでした。

init( _ unexpectedBeforeBase: UnexpectedNodesSyntax? = nil, base: ExprSyntax?, _ unexpectedBetweenBaseAndDot: UnexpectedNodesSyntax? = nil, dot: TokenSyntax, _ unexpectedBetweenDotAndName: UnexpectedNodesSyntax? = nil, name: TokenSyntax, _ unexpectedBetweenNameAndDeclNameArguments: UnexpectedNodesSyntax? = nil, declNameArguments: DeclNameArgumentsSyntax?, _ unexpectedAfterDeclNameArguments: UnexpectedNodesSyntax? = nil ) {

なるほどね。

あーそうかそもそもドットの左側はいろんな式が書けるけど

6:03 PM

右側は静的な文字列しか来ないのか

libSyntax 削除のクソデカ PR がとうとう出てました https://github.com/apple/swift/pull/62145

Delete libSyntax by CodaFi · Pull Request #62145 · apple/swift

Now that swift-syntax no longer consumes the serialized parse tree (see apple/swift-syntax#1041), and we are no longer building the internal swift-syntax dylib (see #61898), we are finally able to ...

おー、すげー、やったー

完全SwiftParser版のバージョンタグ出荷まだかなあ

8:29 AM

Swift 5.8 ? のときに出るのかな。

https://github.com/apple/swift-syntax/pull/1113

Format the swift-syntax repository using swift-format by ahoppen · ...

This does not format the generated files because it’s harder to debug generator changes if the newly generated files need to be formatted to get a meaningful diff. This PR is intended to spark the ...

4:50 PM

swiftsyntaxがswift-formatかけようとしてる。

お、その勢いですべての標準のフォーマッタとしてXcodeに組み込まれてほしい。

xcodeに組み込まれてほしい超同意

今までは#imageLiteral(...)、#colorLiteral(...)はObjectLiteralExpr、#selector(...)はObjcSelectorExprだったのが最新のSwiftSyntaxだと全部MacroExpansionExprSyntaxになってるな。

https://github.com/apple/swift-syntax/tree/main/EditorExtension

swift-syntax/EditorExtension at main · apple/swift-syntax

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swift-syntax/EditorExtension at main · apple/swift-syntax

12:57 PM

SwiftSyntaxを使って実装されたソースコードリファクタリングツールの SwiftRefactor と、それをXcodeから呼び出すための EditorExtension が生まれてた

1

12:58 PM

/// ## Before /// /// if let foo = foo { /// // ... /// } /// /// /// ## After /// /// if let foo { /// // ... /// } (edited)

12:58 PM

新しいif letにするやつとか入ってるっぽい

いいね。ファイルをまたがるリネームはできるかな。

public protocol RefactoringProvider { /// The type of syntax this refactoring action accepts. associatedtype Input: SyntaxProtocol = SourceFileSyntax /// The type of syntax this refactoring action returns. associatedtype Output: SyntaxProtocol = SourceFileSyntax /// Contextual information used by the refactoring action. associatedtype Context = Void /// Perform the refactoring action on the provided syntax node. /// /// - Parameters: /// - syntax: The syntax to transform. /// - context: Contextual information used by the refactoring action. /// - Returns: The result of applying the refactoring action, or `nil` if the /// action could not be performed. static func refactor(syntax: Self.Input, in context: Self.Context) -> Self.Output? }

なんか入力と出力がワンファイルな雰囲気(Output = SourceFileSyntax)はあるけどどうなんだろう (edited)

そもそもSwiftSyntaxだと型情報を見る必要があるやつはまだ無理か。

2:47 PM

XcodeがつかってるリファクタリングじゃなくてSwiftSyntaxをリファクタリングに使おうとしたときに便利に作れるユーティリティということだな・

そうですね。

Package.swift を自動編集するコードをSwiftSyntax上で組もうとしてるけど思いの外難しい (edited)

9:09 AM

SyntaxRewriterのvisit APIに、「自身を変更せずに子を訪問する」制御が無いのって、書き換えたい種類のノードが、ルートから見て２回以上入れ子になっている場合に厳しくない？

SyntaxRewriter.visitChildren は RawSyntax とか使ってるのでコピペできない

9:21 AM

ユーザーレベルで等価な処理を実装するのも、できないような気がする・・・

9:21 AM

node.children は取れるけど、それを map { visit($0) } した配列からノードに戻す方法がない

9:22 AM

FunctionCallExprSyntaxBuilder みたいな具体的なbuilderを使って子ノードを具体的に置き換えていくコードを明示的に書かないといけない？

まあ直面してるユースケースだと実際には目的のノードはルートから見て表層にあるから

9:41 AM

大丈夫なんだけど気持ちが悪い。

https://forums.swift.org/t/se-0382-expression-macros/62090/10

We are looking to improve the SwiftSyntax documentation, as well as providing more examples for folks to start from.

SwiftSyntaxのドキュメントやサンプルもマクロと一緒に整備される（かもしれない）。期待しすぎないように待つことにする。

SE-0382: Expression Macros

and... are great feedback, thank you. We are looking to improve the SwiftSyntax documentation, as well as providing more examples for folks to start from. Most of time, removing a @MainActor or @escaping will cause type-checking failures. The same is true for @expression on macros. Swift is consistent about having introducers (func, var, s...

https://github.com/apple/swift-syntax/pull/1168/files ドキュメントちょっと増えた

[Gardening] Expand SwiftSyntax's Documentation by CodaFi · Pull Req...

Clean up some broken links in doc strings and reorganize some parser documentation to better reflect current practices.

1

## Syntax Nodes A syntax tree is made up of elements called syntax nodes. To help categorize and organize syntax nodes, SwiftSyntax defines a hierarchy of protocols for syntax nodes. At the top of this hierarchy is the ``SyntaxProtocol`` protocol. To represent related categories of syntax, ``SyntaxProtocol`` is further refined: - ``DeclSyntaxProtocol`` for declarations like `struct`s, `class`es, `enum`s and `protocol`s. - ``StmtSyntaxProtocol`` for statements like `if`, `switch`, and `do`. - ``ExprSyntaxProtocol`` for expressions like function calls, literals, and closures - ``TypeSyntaxProtocol`` for types like `Array<String>`, `[String: String]`, and `some Protocol` - ``PatternSyntaxProtocol`` for patterns like `case (_, let x)` Syntax nodes form the "branches" of the syntax tree, as they are generally high-level collections of one or more syntax nodes. Taken together, these branches form the syntactic structure of the source code. This structure is used by compilers and static analyzers to process source code at a high level. A special kind of syntax node is a ``SyntaxCollection``, which represents syntax with a variable number of children. For example, a code block value can contain zero or more statements in between a pair of braces. To represent these children, a ``CodeBlockSyntax`` value has a ``CodeBlockSyntax/statements`` accessor that returns a ``CodeBlockItemListSyntax`` value. The elements of this syntax collection are ``CodeBlockItemSyntax`` values.

これいいな。こういう体系的な情報はドキュメントに書いてくれないとわからんから。できれば網羅して書いてほしいけど。

SwiftRefactorのExtensionが実装してるこのコードって https://github.com/apple/swift-syntax/blob/main/EditorExtension/SwiftRefactorExtension/CommandDiscovery.swift SwiftRefactorモジュールに含まれるRefactoringProviderに準拠している型を動的に取得してるのよね。プラグイン的な挙動が実現できるわけか。

swift-syntax/CommandDiscovery.swift at main · apple/swift-syntax

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swift-syntax/CommandDiscovery.swift at main · apple/swift-syntax

Kishikawa Katsumi

XcodeがつかってるリファクタリングじゃなくてSwiftSyntaxをリファクタリングに使おうとしたときに便利に作れるユーティリティということだな・

これちょっと違ったな。リファクタリングを書くのが簡単になるものかと思ってたけどサンプルコード集だな。

https://github.com/apple/swift-syntax/releases/tag/0.50800.0-SNAPSHOT-2022-12-20-a

Release 0.50800.0-SNAPSHOT-2022-12-20-a · apple/swift-syntax

This is a development snapshot of the 0.50800.0 release of SwiftSyntax. To use this snapshot add the following dependency to your Package.swift: .package(url: "https://github.com/apple/swift-s...

2:53 PM

きたー

昔SwiftSyntaxがSwiftコンパイラ内部のlibSyntaxだったころに、リポジトリの中でTriviaのパースの規則について書いてある文書を読んだ記憶があるんですが

7:37 AM

SwiftSyntaxリポジトリの中から同じ話をみつけられなくて

7:39 AM

コンパイラ側からもなくなっちゃった？気がするんですけど

7:39 AM

誰かわかりますか

これですか？ https://github.com/apple/swift/blob/980d40951ff557047dce833d1d092b400bbc20db/lib/Syntax/README.md

swift/README.md at 980d40951ff557047dce833d1d092b400bbc20db · apple...

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

これだ

7:40 AM

There are two Rules of Trivia that you should obey when parsing or constructing new Syntax nodes: A token owns all of its trailing trivia up to, but not including, the next newline character. Looking backward in the text, a token owns all of the leading trivia up to and including the first newline character.

7:41 AM

この話swift syntaxリポジトリにあるかな？

7:41 AM

とりあえず今は内容が知りたかったので解決しましたが

7:44 AM

改行が来るまではtrailing triviaで、それ以降はleading triviaか。

たいした情報じゃないかもですが共有です https://twitter.com/the_uhooi/status/1618148272400633857?s=46&t=R-vGvQnwDY-Slcat6NTPhQ

ウホーイ (@the_uhooi)

マージされたので、Swift 5.7 で Swift Syntax を使うなら 0.50700.0 より 0.50700.1 のほうがいいと思いますー！✨

2

今回から versioning スキームが変わってますが、5.8 対応リリースです https://github.com/apple/swift-syntax/releases/tag/508.0.0

Release 508.0.0 · apple/swift-syntax

This is the 508.0.0 release of SwiftSyntax, aligned with the release of Swift 5.8. To use this snapshot add the following dependency to your Package.swift: .package(url: "https://github.com/ap...

2

これを待ってた

キターーーー

11:33 PM

0.xxx じゃないけど sem ver 準拠はしてるのかな

11:34 PM

いきなりメジャーバージョンが508になったのか

リリース毎に破壊的変更が入る前提なのかと思います。

5.9で509になりそうだから下位互換なんて無いんですよって意思表示か

rintaro

リリース毎に破壊的変更が入る前提なのかと思います。

なるほど　まあそもそも言語の文法次第だし妥当そう

"#!/bin/env swift" を解釈するようになった。Swiftをスクリプトっぽく動かすのが便利になるような機能が入るのかしら。

swift scriptモードはなんか進んでましたね

へえ

11:44 PM

ライブラリインポートしたりできるようになったりするのかな。

https://forums.swift.org/t/pre-pitch-package-argument-syntax/63031

Pre-Pitch: @package argument syntax

Hello folks at the Swift community! A year and a while ago, I started the work of supporting @package(...) import syntax for importing SwiftPM dependencies in Swift scripts as a GSoC project. During the project, I managed to work out a proof-of-concept of this feature with Swift Driver integration. The PoC implementation consists of a small sta...

11:48 PM

@package(...) import Yams って感じらしい

Goっぽい感じかな。

この importについてる @package もSwiftSyntaxでパースできるようになったのかな？

そっちは何か増えてるようなことはなかったけどどうだろう。shebangはLeadingTriviaとして解釈されるみたい。

なるほど

Shebangは最初の文のLeading Triviaになる。

1:13 AM

最初の文、っていうかとにかくLeading Triviaになる。

triviaの種類にshebangってあるんでしたっけ

1:14 AM

https://github.com/apple/swift-syntax/blob/main/Sources/SwiftSyntax/generated/Trivia.swift#L49-L50

swift-syntax/Trivia.swift at main · apple/swift-syntax

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swift-syntax/Trivia.swift at main · apple/swift-syntax

1:14 AM

/// A script command, starting with '#!'. case shebang(String)

1:14 AM

あった

508.00で増えたやつ。トークンの種類でいうとgarbageTextがなくなってshebangとunexpectedTextが増えた。 (edited)

garbageはやめたんですね

1:24 AM

確かに他のところでもunexpectedって言葉使ってるしその方が一貫性がある

私はgarbageは中途半端なUTF8とかそういうのだと思ってたわ。

あれ？そういえばそうですね

1:44 AM

swift syntaxはbytes to bytes roundtripじゃなかったっけ

1:44 AM

case unexpectedText(String)

1:44 AM

これだとStringだから不正なバイトシーケンスは扱えなさそう

内部的にはバイト列でもっていて、たしか現状だと Syntax.syntaxTextBytes のみが不正UTF8バイトシーケンス取得できるとおもいます。 https://github.com/apple/swift-syntax/blob/cb3f64d9d4f0efeb23cab8fe458e5195b8900089/Sources/SwiftSyntax/Syntax.swift#L553-L557

2:56 AM

garbage -> unexpected に関してはユーザーのコードを garbage 呼ばわりするのは失礼だっていう話でした、まじめに。 https://github.com/apple/swift/pull/60563

言葉の問題でしたか。

rintaro

内部的にはバイト列でもっていて、たしか現状だと Syntax.syntaxTextBytes のみが不正UTF8バイトシーケンス取得できるとおもいます。 https://github.com/apple/swift-syntax/blob/cb3f64d9d4f0efeb23cab8fe458e5195b8900089/Sources/SwiftSyntax/Syntax.swift#L553-L557

そうすると、LeadingTriviaにunexpectedTokenがあって、そこにあるバイト値が知りたい場合、(Triviaのインターフェースからではなく) そのLeadingTriviaがくっついているSyntaxNode自体のsyntaxTextBytesを見ればいいんですかね？ (edited)

omochimetaru

そうすると、LeadingTriviaにunexpectedTokenがあって、そこにあるバイト値が知りたい場合、(Triviaのインターフェースからではなく) そのLeadingTriviaがくっついているSyntaxNode自体のsyntaxTextBytesを見ればいいんですかね？ (edited)

そうですね、逆に言えばそれしか手段ないかもですね。

なるほど。トリッキーでわかりにくいけど、まあ普通は正しいStringしか気にしたくないしいいような気もする

https://github.com/apple/swift-syntax/pull/1520 ちょっとおもしろい事象を修正した。

Fix escape handling for emoji #️⃣ in string literals by kishikawa...

This pull request addresses an issue with the escape handling when counting the number of # characters in string literals. Previously, the code didn't consider the emoji #️⃣ presence. This resu...

1

ええ？？？

#️⃣は「◻︎#」だからうまいこと#で囲むようなリテラル #"...#️⃣..."#になったらダメなケースがある、みたいな。

問題なさそうに見えますが、これだとだめな場合がある？

12:46 AM

あいや、そこにダブルクォートがいるのか

12:47 AM

ほんとだ、ぶっ壊れた

12:48 AM

えーとつまり、"#️⃣ がエスケープリテラルを閉じる "# として処理されてしまっている？

12:48 AM

そもそもがこれエスケープ文字列リテラルの処理のバグなんじゃないか

あ、そうだね。そのケース。そう。◻︎#だから右側#が拾われてる。

12:50 AM

コンパイルを通す場合、両側の#を増やす必要があるけど、SwiftSyntaxのリテラルを作るコードがリテラル中の#を数えるのを絵文字の場合は見逃してた、っていうのを修正したんだけど

12:50 AM

大元を直す方がいい感じなのかな。

逆にこれが通らないのもおかしい

12:53 AM

「囲み文字」＋「シャープ」　に対して、囲み文字をゴミとして読み飛ばすのであれば、これで閉じられるはず

本当やな。それ通らないのはなんか処理が一貫してないな。

12:56 AM

バイトシーケンスとしては、 # + variation selector + enclosing keycap らしい

12:56 AM

シャープ記号は右側にあるんじゃなくて、シャープ文字は左側にあるみたいです。 (edited)

12:57 AM

だから実際unicode scalarで見るとちゃんと「double quote + ascii pound 」の並びになっていて、エスケープリテラルの閉じカッコがあるようにみえる。ゴミは右側に付いてるんだ、これは難しいな　先読みしないとわからないぞ。 (edited)

あ、左側か。

バリエーションセレクタとかいう仕様終わってますね。

omochimetaru

逆にこれが通らないのもおかしい

このエラーメッセージは、#️⃣によってリテラルを閉じる事は成功しているけど、その後ろにあるvariation selector と eclosing keycap がゴミ文字になっていて、それで「cannot find (enclosing keycap) in scope」って言ってるんですね・・・囲みマーク1文字のキーワードだと思ってるのか。

Kishikawa Katsumi

大元を直す方がいい感じなのかな。

大本を治すのは難しそうｗ

ね、難しそうだ。

1:02 AM

もしかしてマクロとか#️⃣先頭で動くのか。。。？？

ｗｗｗ

意味があるとは思えないけど動きそうだ。

マクロの名前が「VS + keycap + foo」みたいにしておけばいけるかもｗ

なんか動きそうな気がする。意味ないけど気になるから後でやってみよう。

https://github.com/apple/swift-syntax/blob/main/Sources/SwiftParser/Lexer/Cursor.swift#L1001-L1011

swift-syntax/Cursor.swift at main · apple/swift-syntax

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swift-syntax/Cursor.swift at main · apple/swift-syntax

1:06 AM

多分直すべきはここかな？ unicode characterじゃなくてそもそもutf-8 bytesで読んでいて、場合に応じて unicode scalar を食うみたいになってるので

1:06 AM

ここだけvariation selectorまで考えるのちょっとコードがなじまないし、

1:06 AM

他の場所にも変なバグがありそうですねえ

1:08 AM

変なバグあった。

1:08 AM

Invalid Swift parseable output message (malformed JSON)

そうなのよね。書記素クラスタ単位で読むわけじゃないんよね。

ツールチェインがぶっ壊れてる・・・

Emoji関連おもしろいな。片っぱしから報告していこう。

なんか囲み文字を不正に使いつつコンパイル通せないかなあ

1:10 AM

⃣ ↑(単体の囲み文字) がどうしてもエラーを引き起こしてしまう (edited)

各種カッコ、<>、＠みたいなものが混ざる絵文字を駆使するとなんか起こりそう。

1:19 AM

はてなとビックリもたぶんなんかあるぞ。

そうか、そのへんもバリエーション系なのかｗ

あと基本的にVariation selectorとかそういう不可視の文字は絵文字として用意されてない組み合わせも文字列としては存在するから難しいよね。見た目のレンダリングするソフトウェアがどうUnicodeを処理するかとコンパイラは全然関係ない、みたいな。

Kishikawa Katsumi

あと基本的にVariation selectorとかそういう不可視の文字は絵文字として用意されてない組み合わせも文字列としては存在するから難しいよね。見た目のレンダリングするソフトウェアがどうUnicodeを処理するかとコンパイラは全然関係ない、みたいな。

絵文字パレットに図版が存在しない組み合わせもあるって話ですよね。

1:27 AM

そういう場合もVSがついてるならcharacterとしては結合しておくべきなのかな・・・？

たしか書記素クラスタの分割ルールっていうのがあるんすよね。

1:29 AM

だからVariation selectorじゃないけどこういう肌の色を変えるやつは対応してない組み合わせだと単独で表示される、みたいな。

‍

データとしては結合して一文字扱いにして、レンダラーでまた部品にバラす、のがお行儀よさそう

Swiftは（macOSは？わからん）

‍

は１文字の書記素クラスタとして扱うはず。ただ見た目は３文字。。。

1:31 AM

選択すると間を選択できないから。

1:36 AM

でもこれが１文字扱いになるのは正直まったく便利ではない。

let 🇯🇵 = "Japan" let 😕🏻‍🦰 = "first character is not an `Emoji_Modifier_Base`" let #️⃣ = "Pound sign" // Compilation error

絵文字の変数名は使えるしおかしな合成文字も変数名にできるけど#️⃣は無理っていうのはなんか困る気がしないでもない。

let # = が駄目だからかな　絵文字にも文字っぽいやつと記号っぽいやつがあるんすね

絵文字を相手にするプログラミングはなかなかしんどいな。Unicodeの仕様はなんやかんやでよく考えられてると思うけどあれはどういうバランスで何を優先してるんだろう。見た目の統一みたいなのは優先度高くない印象。

6:34 AM

let ‼️ = "bikkuri" let ❓ = "hatena" let ❔ = "white hatena" はてなとビックリもだめだな。まあ一貫している気がする。

6:34 AM

‼️ビックリはこれを入力した。

http://www.unicode.org/reports/tr51/#Longer_Term もうSwift全然関係ない話題になっちゃうんだけど、絵文字の長期的な目標としては埋め込み画像のサポートって書いてあった。つまりこの辺のややこしい仕様は超長期的には全部いらなくなって自由に好きな絵文字を使えるようになるということだろうか？

1

Discordとかまさに今そうなってますよね。絵文字がDiscordサーバーに登録されてるから、Discordの外には持ち出せないけど。

あー、確かに自分でアップロードして絵文字にするやつはそうなんだなあ。いずれそういうのも相互運用できるようになっていくとかあるのかな。

仕組み的にはHTMLのimgタグって必要なもの全部持ってますよねｗ <img src="https://emoji.discord.com/ABCDABCD" />

1:35 AM

画像だけホスティングするサーバーが一人だけ損するから実現してない気がする。

imgタグ内にbase64で仕込めば完結しそうではありそうですね。(もちろんそのテキストデータホストする人が辛いけれど)

埋め込みだと複数回使うときの効率が悪いのが気になるんですよね

いろいろなことを無視すれば絵文字をホストするサーバーはいろんな情報が取れるからやるところはある気がしないでもないけどまあ広く使われるのは難しそうだな。

1:40 AM

ただまあ技術でなんとかなりそうな感じはある。バイナリで埋め込むのも将来的にはアリになりそうな感じもだいぶある。

1:42 AM

で、絵文字を調べてて本当にやりたかったことはタテのカラムを合わせたかったんですよね。

|⌚|⭐|⺎|⽋|🇯🇵|🗿|🗿|豈|Ａ|🚀| |ab|cd|ef|あ|い|う|え|お|12|34|5| |ab|cd|ef|あ|い|う|え|お|12|34|5| |⌚|⭐|⺎|⽋|🇯🇵|🗿|🗿|豈|Ａ|🚀| |ab|cd|ef|あ|い|う|え|お|12|34|5|

ただどうやっても絵文字が混ざった時点でどうしようもないことがわかった。

1:43 AM

Terminal Emulatorなら基本的に幅は一定なので絵文字がどうレンダリングされるかが分かればいけるんだけど端末ごとに絵文字のレンダリング結果が違うから端末ごとにテーブルを持つことになりそうでやっぱりどうしようもなかった。

あー PowerAssertの結果表示の関係ですか？

そうなんです。

ああ〜

AppleのTerminal.appだけ考えても、

1:46 AM

こういうValidな絵文字だけについても

1:47 AM

Terminal.appだと対応されてないものがあるので、テーブルを持つことになる。

1:47 AM

レンダリングの結果をテーブルで持てばタテは揃うけどね。

1:48 AM

ということで絵文字はシングルトンのものを除いて\u{1234}みたいな形で表現しようかなあと考え中。

ver 508 で結構API変わってるな

11:23 PM

PatternBindingSyntax.Accessor が enum になったり

11:23 PM

FunctionSignatureSyntax.parameter が .input になったりしている

11:25 PM

TypealiasDeclSyntax.initializer のオプショナルが取れてるｗ

11:25 PM

空の場合は MissingType が入ってた。 (edited)

SwiftSyntax、debugDescriptionでツリー構造をアスキーアートで出力してくれるようになっってみやすくなったんだけど、そのタイミングで https://github.com/apple/swift-syntax/blob/a9cff1a33af9f5b1a9cc26a5d35049ffa3a3eda8/Sources/SwiftSyntax/Syntax.swift#L609-L612 debugDescriptionが見やすくなったからMirrorはむしろ邪魔だよねっていうことでMirrorを無くしたんだけどそれはそれですごい決断だなって思った。私としてはMirrorもあったほうがMirror使いたいときにいいと思うんだけど。

swift-syntax/Sources/SwiftSyntax/Syntax.swift at a9cff1a33af9f5b1a9...

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swift-syntax/Sources/SwiftSyntax/Syntax.swift at a9cff1a33af9f5b1a9cc26a5d35049ffa3a3eda8 · apple...

僕もそう思います。Mirrorでなにかやってた人は不便そう。debug descriptionは文字列だからコードからそれ以上操作できないし。でも、多くのユーザはswift-ast-explorerがあればどっちもいらないからあんまり困らなそう。 (edited)

8:08 AM

それこそ、Mirrorはswift-ast-explorerを実装するときぐらいしか用途がないんじゃないか、とは思いました。

そう、私が困ったというだけかもしれない。Mirrorと同じことは一応debugDescriptionと同じことすればできるからできるんだけど、私からみるとまさかMirrorがまるまる空が返ってくるとは思ってなかったからかなり衝撃的な変更だった。 (edited)

使ってる人にとっては派手ですね

とつぜん空っぽになったからね。環境を疑ったわ。

ww

Swift AST ExplorerでSwiftSyntaxのバージョン切り替えられるようにした。それぞれのバージョンで微妙に構文木が違う場合があるけど普通は気にしないで問題ないと思うし、SwiftSyntaxはバージョン間のソースコード互換性がないのでただただ面倒なんだけどもしかしたら一人くらいほしい人がいるかと思って作った。

2

3:05 PM

いちおう私にとってはSwiftSyntax更新したらここが壊れるんやなっていうのがあらかじめわかるのは利点ではある。

久しぶりにSwiftSyntaxのコード見てますが、今更だけどSwiftParserが出来たの便利な世の中だ。ただSwift CompilerはlibSyntaxではない？けどまだC++なんですね。

4:08 AM

あとうろ覚えですがswift-astを作るとかいう話が遥か昔にありませんでしたっけ？SwiftParserの次はASTもあると良いですね。

SwiftSyntaxからASTをつくるlib/ASTGenってコンポーネントがあるよ完成してて有効化されてるのか作業途中なのかは追ってなくてわからない

ほんとだ！ASTがまだC++だったからASTGenスルーしてしまった。ASTGenはIDEで使ってるらしい。

4:34 AM

てことはビルドツールでも使えるのかな？Lintとかで型推論無しのASTあるだけでも有用かも。

どうなんだろうコンパイラ無しで単体で使えるのだろうか

まだ無理っぽかった。今後に期待

いつの間にかResultBuilderのSwiftSyntaxBuilderも完成してて便利そう (edited)

@_spiは便利そう https://github.com/apple/swift-syntax/blob/main/Sources/SwiftSyntax/Documentation.docc/Contributing/SPI.md

swift-syntax/Sources/SwiftSyntax/Documentation.docc/Contributing/SP...

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swift-syntax/Sources/SwiftSyntax/Documentation.docc/Contributing/SPI.md at main · apple/swift-syntax

マクロの動作は Text => AST(a) => AST(b) => Text => Compiler だけどAST(b) => TextのところTextにしないで Text => AST(a) => AST(b) => CompilerってASTで渡すほうがいいと思うんだけどなんか理由があってTextにしてたんだったかな。

8:20 PM

というのもAST(b) => TextがあるためにSwiftSyntaxで作るTree構造はトークンレベルでスペース等をちゃんと入れないといけないのがけっこうな負担になってる。で、現在はそれを軽減するためにマクロの出力は自動的にフォーマットされるようになったんだけど（ここで使われるフォーマッタは足りないスペースを適切に足してくれる。フォーマットしない設定もできる。）、現在はフォーマットによって間違ったソースコードが出る場合もあって、それは直ると思うんだけど未発見のケースもたぶんありそうだし、あまりいいやり方と思えないんですよね。

8:22 PM

うーん、でもSwiftSyntaxのASTがTrivia以外まったく同じでもTriviaが空白か改行かで意味が変わることがあるからダメか。

8:24 PM

たとえば下の２つのコードはTrivia以外はまったく同じ構造のTreeにParseされるけど下はコンパイルエラーになるしな。 let a = 1 let b = 2 let a = 1 let b = 2

いや、下の方は正確にはセミコロンがMissing tokenとして自動的に補完されるから区別はできてるよな。

マクロ出力はASTで十分なのそうですよね。

11:56 PM

CST+自動フォーマットでいけるならまあ良さそう

フォーマットはまだ問題のあるケースが多少あるんじゃないかなあ。

12:00 AM

わざわざ問題の起こる箇所を増やしてる感じあるねん。

Swiftのコードを読み取って、TypeScriptのコードに変換するツールを作ってるけど、

12:01 AM

TypeScript出力はASTにして文字列化は自動で綺麗にしてます

12:02 AM

それでちょうど良いと感じてる

最終成果物がTypeScriptのソースコードでそれまではASTなんですよね？

そうですね

マクロは最終成果物がオブジェクトファイルでそれまでは同じようにSyntax Treeでずっといったらいいと思うんですよ。

12:05 AM

テキスト => Syntax Tree => フォーマット => テキスト => Syntax Treeっていうのが合理的じゃないんじゃないかと。

Swift SyntaxのTreeはCSTだけどTriviaを無視したらASTだと思うのでそれでずっとやり取りするのが堅牢だと思うんですよね。

Trivia無視するだけでAST相当なら、自動フォーマットがうまくいくはずな気もする

そうなんですよね。それでいうと現状のフォーマッタが簡易的なものだからっていうのはありますね。

12:24 AM

assertionFailure(""" First line Second line """) 前見つけた問題は上のような複数行文字列リテラルの中の空行をインデントするところが間違っててコンパイルエラーが起こるというものでした。（自動フォーマットで使われてるフォーマッタはインデントもする）ただ、これはフォーマットしなかったら（テキストに出力しなかったら）起こらないはずなんですよ。 (edited)

思い出した

12:26 AM

Packageswiftを編集するコードを書いたんですが、

12:26 AM

関数呼び出しの引数を追加しようとするときに

12:26 AM

途中か末尾かどうかで、カンマをつけるべきかどうかが変わってしまうんですよ

12:26 AM

これはCSTだから必要なめんどくさい処理

12:27 AM

ASTだったら普通はカンマは制御しない、引数の配列を組めばいいだけ

12:27 AM

だからtriviaだけ無視するのでは不足がありますね

確かにカンマはトークンですね。

まあでもノードは区切られてるからカンマは自動で直せそうだな

簡単じゃなさそうだ。この辺りのことはきっと検討した上で現在の方法が採用されてるんだろう。。

変数宣言の型の前に書くコロンはトークンだけど、常に必要だからデフォルト値使っておけばいいな

12:41 AM

トークンだけどあったりなかったりするものがめんどくさい

12:41 AM

カンマぐらいかなあ

AST(b) => Compilerにした場合も AST(b)に対して構文解析が出来る機構になってるんでしたっけ？

たぶん今はそういうのはなさそうな気がします。こうなってたほうがいいんじゃないかなと考えているっていう。

ソースコードを構文解析して出てくるのがASTでは？

なるほど。いや、AST(a) => AST(b) => Compilerだと編集したAST(b)がコンパイル（主に構文解析）できるか担保できてないですよね。

8:37 AM

CompilerはASTをインプットとして受け取れるはずだけど、ASTまでの過程で行うはずの構文解析は終わってる前提な気がする。

ソースコードから生成されえないASTが構築しうるかどうかって事ですかね？どちらにせよその後の意味解析でエラーになるし問題はないような気がする

そうです。AST(b)はmacro用に自前で生成されたものだと思ってました。

ASTは構造化されている代わりにソースコードよりも制約が強い(表現能力が弱い)ので、必ずASTからソースコードが生成できます。ということは、ソースコードから生成されえないASTというのは存在しないと思います。

ソースコードから生成されえないASTが構築しうるかどうかって事ですかね？

いや、この意味じゃなかったです

8:41 AM

マクロの動作は Text => AST(a) => AST(b) => Text => Compiler だけどAST(b) => TextのところTextにしないで Text => AST(a) => AST(b) => Compiler

このAST(b)はAST(a)からコンパイラじゃなくてユーザーがプラグイン経由で生成するで意味合ってますか？ (edited)

コンパイルが通らない，と言う意味なら，通常と同様にASTに対して意味解析を行うので、問題はそこで検出されると思います

kitasuke

マクロの動作は Text => AST(a) => AST(b) => Text => Compiler だけどAST(b) => TextのところTextにしないで Text => AST(a) => AST(b) => Compiler

このAST(b)はAST(a)からコンパイラじゃなくてユーザーがプラグイン経由で生成するで意味合ってますか？ (edited)

ユーザーというかマクロのプログラムですね

そうそう、プラグインね。

マクロのプログラムの入出力をCSTではなくASTにしてはどうか、という話だと思います

マクロのプログラムの入力をTextでなくASTにしたいという話ではないってこと？

8:44 AM

マクロのプログラムというか、上記でいうCompilerの入力

岸川さんが言ってるのは両方かな？マクロプラグインは、ASTを受け取ってASTを返すインターフェースにする。出力されたASTはそのままコンパイラが使えれば効率的。

8:48 AM

多分今のコンパイラはマクロプラグインが出力したCSTを一度ソースコードにして、それをまたパースしてるんじゃないか・・・？

両方なのね

それともそのまま(CSTをソースコードにしないまま)ASTgenしてるのかな？ (edited)

僕の論点としては、編集された出力されたASTが構文的に正しいのかを担保できてるのかという点です。

8:50 AM

ASTGenがASTの生成できた = 構文エラーはないってことですかね？

kitasuke

僕の論点としては、編集された出力されたASTが構文的に正しいのかを担保できてるのかという点です。

それについての僕の意見はASTの性質から絶対に構文的に正しいという事ですね

8:50 AM

https://github.com/omochi/TypeScriptAST

GitHub - omochi/TypeScriptAST

Contribute to omochi/TypeScriptAST development by creating an account on GitHub.

そうなのか

これはTypeScriptの自作のASTですが、

8:50 AM

必ず文法的には正しいTypeScriptコードになります (edited)

8:51 AM

意味的には正しくない可能性があるからその先の意味解析でエラーになることはありえます

意味解析はそうね。それなら確かにTextじゃなくてAST(b)のまま渡すのが良さそう

それともそのまま(CSTをソースコードにしないまま)ASTgenしてるのかな？

余談だけど、マクロのプラグインはおそらくASTGenではCSTの生成までな気がしてる。これはまだ見つけられてないけど、このCSTがプラグインのメッセージとして返されてSwiftSyntaxかSourceKitか何かがソースコードに変換してるんじゃないかと予想してる https://github.com/apple/swift/blob/53da6759de6f36e48da70ed7174ce1ff6aadf7c4/lib/ASTGen/Sources/ASTGen/PluginHost.swift#L379 (edited)

swift/lib/ASTGen/Sources/ASTGen/PluginHost.swift at 53da6759de6f36e...

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

マクロのプログラムの入力をTextでなくASTにしたいという話ではないってこと？

マクロプラグインは、ASTを受け取ってASTを返すインターフェースにする。

マクロの出力をTextからASTにしたいという話なのですが、今はマクロのインターフェースはASTを受け取ってASTを返すというものになってるんです。けれど実際は、マクロが返したASTがテキストになって、コンパイラは再度そのテキストをParseしてコンパイルするっていう動作をします。私はそこをASTのまま扱ってほしいと考えています。

9:36 AM

で、具体的に起こってる問題はマクロはASTを返すのだけどSwiftSyntaxのSyntax Treeはスペース等も含めた構造を構築しないと後続でコンパイルエラーになるからちょっと大変。なので少し前にスペース等を自動的に挿入してくれるようにデフォルトで自動フォーマットする処理が入った（BasicFormat）。ただ、そのために複数文字列リテラルで不要なインデントを挿入してしまってコンパイルエラーが起こるなど本来なら起こらないはずの問題が起こっている。なので、AST => Text => コンパイラじゃなくてAST => コンパイラの方がいいのでは、という意見です。 (edited)

BasicFormatはそういう機能なんですね。AST => コンパイラは内部的にはそれが良さそうですよね。最終的な出力としてはXcode上でマクロが展開されたソースコードをユーザーが見れるようにする必要はあるで合ってますか？それを手っ取り早く実現するためにTextで扱ってるような気がしてます。

最終的な出力としてはXcode上でマクロが展開されたソースコードをユーザーが見れるようにする必要はあるで合ってますか？

これはあった方がいいと思う。マクロをデバッグしたり、そのままコピーして動かしたりすることはよくあるので。確かに今はXcodeが展開してくれるものとコンパイラに渡るものが一致しているからそれはそれで利点がありますね。

理解しました。そしたらやっぱりマクロのプラグインとコンパイラのやり取りはASTが入出力になるのが綺麗ですね。

11:27 AM

その上でXcodeが展開するのはソースコードにして欲しいけど、結局はその部分で不要なインデント等のコンパイルエラーは起きうるかもしれないですね。

11:28 AM

コンパイラに渡るものが若干形式変わるけど、ただASTとそのASTから生成ソースコードなので完全一致とはいかなくても問題はなさそう。

11:30 AM

その上でXcodeが展開するのはソースコードにして欲しいけど、結局はその部分で不要なインデント等のコンパイルエラーは起きうるかもしれないですね。

違うか。おもちさんが言うASTからは絶対に文法的に正しいコードしか出力されないのであれば、この問題は解消されるような。 (edited)

おもちメタルさんの作ったTypeScriptのASTはたぶんそうなるようにがんばってるからそうなんだと思う。 SwiftSyntaxが生成するStructureは設計思想の違いもあって、文法的に間違ったSyntax Treeも作れるのですよね。なのでSwiftSyntaxでTreeを作る場合はそこそこ丁寧な作業を求められる。そこでSwiftSyntaxの現在の提案としてはBasicFormatを自動で実行することででだいぶ楽になるんじゃない？っていうのが今の状況だと思う。で、私はBasicFormatの不具合に当たったのであんまりそれは良くないんじゃないかと思っている、みたいな。

Kishikawa Katsumi

おもちメタルさんの作ったTypeScriptのASTはたぶんそうなるようにがんばってるからそうなんだと思う。 SwiftSyntaxが生成するStructureは設計思想の違いもあって、文法的に間違ったSyntax Treeも作れるのですよね。なのでSwiftSyntaxでTreeを作る場合はそこそこ丁寧な作業を求められる。そこでSwiftSyntaxの現在の提案としてはBasicFormatを自動で実行することででだいぶ楽になるんじゃない？っていうのが今の状況だと思う。で、私はBasicFormatの不具合に当たったのであんまりそれは良くないんじゃないかと思っている、みたいな。

ちょっと話がズレてそう。 SwiftSyntaxが提供しているのはCSTで、AST ではない 、という認識で、 ASTは Swift compiler内部の libAST のノードツリーのことを指してます。 (edited)

あ、ごめんなさい。ズレてますね。リセットして最初に戻ると、マクロがコンパイルされるときには、テキストからSwiftSyntaxのSyntax Treeになって、さらにテキストになってコンパイラに渡される、けどSyntax Treeのまま渡す方が問題が起こることが少ないんじゃないかという意見です。

Kishikawa Katsumi

あ、ごめんなさい。ズレてますね。リセットして最初に戻ると、マクロがコンパイルされるときには、テキストからSwiftSyntaxのSyntax Treeになって、さらにテキストになってコンパイラに渡される、けどSyntax Treeのまま渡す方が問題が起こることが少ないんじゃないかという意見です。

パイプラインとしてはそれでもいいと思うんですけど、 Xcodeで直接expand macroできたり、expandした状態を可視化したりする機能はほしいですよね。そうすると結局マクロ適用した後のテキストとしてのコード、というものからは逃れられないのでは。

10:53 AM

そして、そのテキストとしてのコードをコンパイルした結果と、SyntaxTreeそのまま渡した結果は、当然同じじゃないと混乱を招くので、結局テキスト化したものを処理する、という形になりそう

Syntax Treeの段階で文法エラーが起こり得る場合は状況はより悪くなるんですけど、Syntax Treeの段階で文法エラーが起こらないなら見せるテキストはSyntax Treeから適宜生成したテキストでいいと思うんですよ。単なるプレゼンテーションの１つ、みたいな。その先でコンパイルエラーが起こるのは変数の衝突とか書き方の違いじゃないから大丈夫と思うし。

Swift のマクロは思想的にはテキスト書き換えに近いと思います。SwiftSyntaxでやりとりしているのはテキストそのままよりはマクロ実装者が便利だろうと考えているからだと思います。テキストを介するおおきな理由の一つとして、コンパイラの swift-syntax とマクロプラグインの swift-syntax のバージョン差異の吸収というのがあります。たとえば Swift 5.10 で新しい文法が導入されたとして、5.10コンパイラから swift-syntax-509.x 向けに作られたプラグインを使う場合、 5.9 の swift-syntax はそれを表現する手段を持ちません。が、テキストを介せばその新しい文法も unexpectedBetweenXXXandYYY としてパースされるなど、何らかの形で_そのまま_マクロ実装に渡ります。マクロ実装は文法エラーのある Syntax Tree を受け取りますが、前後になにか足したりするだけでその内容を扱わないのであれば、expected* がまたそのままテキスト化されてコンパイラに返り、コンパイラは 5.10 の swift-syntax でそれをパースすることによって、新しい文法が適切に解釈されるという形です。 (edited)

Syntax Treeの段階で文法エラーが起こり得る場合

SwiftSyntax は CST なので文法エラーのあるテキストでも unexpectedXXX などで表現できます。ExprSyntax("func foo() {}") もExprSyntaxとしてはパースエラーですが、それでもツリー生成はされます。あと SwfitSyntax は入力テキストのバリデーションを行わないので極端な例ですが IdentifierExprSyntax(identifier: TokenSyntax(.identifier("var value = 1"), presence: .present)) も通ります。 (edited)

やろうと思うとなんでもできる柔軟性があるっていうのはいいと思います。ただ多くのケースでは文法として正しいツリー構造を文法的に正しいツリーを維持したまま操作するのでそういう場合にテキストに戻すことでエラーが起こりうるよりはそうじゃない方がいいかなと思ったんですよね。

SwiftSyntaxが最新版でちょっとツリーの構造が変わって作ってるマクロで対応が必要だった。

9:10 AM

bar.foo.val はもともと上のようなツリーになってたんだけど、

9:14 AM

各変数がトークンじゃなくてDeclReferenceExprSyntax（旧IdentifierExprSyntax）に包まれるようになった。それで各変数１つ１つが要素として評価されるようになったので元のツリーだったら、 bar.foo.val、bar.foo、barとうまいことツリーが探索されてたのだけど、新しい構造だとbar、foo、valが単独でSyntax要素になったので単独で探索に引っかかるようになった。

おお、地味に壊れるところが出てきそうですね

ウチのはめためたに壊れた。

9:27 AM

Linterとか影響ありそう。

decl referenceなるほど

トークンだ、と思ってたのがSyntaxになったり階層が増えるっていうのはその辺の構造をチェックするやつに影響ありそう。

Meta Meta

あと、たぶんAPIの名前をキレイにしてる。 https://github.com/kishikawakatsumi/swift-power-assert/pull/255/files これはめっちゃ変わってるように見えるけどごく一部で、 https://github.com/SwiftFiddle/swift-ast-explorer/pull/319/files プロパティの１つ１つを一貫性がある名前に整理してる。ここ１か月くらいSwiftSyntaxの変更があるたびにめっちゃ名前変わってる。

互換性を維持していくの大変そうだな。なんとなく複数バージョンをメンテすることになるんかなと思ってるけど。（Swift 5.9用のライブラリ、6.0用のライブラリ、みたいな。）

そうですね。

11:45 PM

でも実行環境の対応バージョンと違って、開発環境のバージョンは上げやすいから、最新のXcodeと最新のXcode betaの2系統だけの保守で足りそう

1

自分としては各Xcodeに対応したバージョンをメンテするのはできるんだけどSemantic Versioningとその周辺のツールと相性が良くないねんな。

1:52 AM

https://forums.swift.org/t/macro-adoption-concerns-around-swiftsyntax/66588 ちょうど問題提起がStephenさんからされてたわ。

Macro Adoption Concerns around SwiftSyntax

Macros are one of the most celebrated new features of Swift, and many of us are excited to adopt them in our projects. Many members of the core team are also excited to suggest macros as a solution to many problems. We’d love to hit the ground running and adopt macros in our projects, but the decision to adopt them raises some questions, particu...

1:52 AM

Appleも問題を認識してるけど特に解決はされていない。

1:54 AM

ユーザー側でできる方法としては各自SwiftSyntaxをForkしてバージョンごとに違う名前に変えてライブラリに内包してしまう、などがある。

1:54 AM

^ まあこれはジョーク（皮肉）ですね。 (edited)

確かに問題提起しようと思うくらいには最近の変更量はMacro関係無しに多かったですね

6:13 AM

SwiftSyntaxの動向を観察してると、当分は基本的に最新のXcode betaへの対応をメインで考えてそう (edited)

実際SwiftSyntaxをforkしてるプロジェクトは幾つか観測してますね…

SwiftSyntaxはバージョン507になったときにその意思をはっきりしてますよね

8:35 AM

Swiftのマイナーバージョンがあがるときは、SwiftSyntaxのメジャーバージョンが上がるから

8:36 AM

そもそもSwiftSyntaxの2バージョンをまたいだ互換プログラムは書けない、書けるようにするつもりがない

8:37 AM

SwiftSyntax自体も昔はxcodeのバージョンと紐づいて分裂してて、swift-formatとかはSwiftSyntaxに引っ張られて同じようにバージョンが分裂している

8:38 AM

よくはないだろうけど現実的に仕方ないと思う

もっと気軽にSwiftSyntaxに依存できればいいのに今のところは気合い入れて追従するか使わないかって感じなんですね…

swift-formatは開発用はSwiftSyntaxのmasterブランチを見てるので、追従するPRが多いです。そしてahoppenさんがSwiftSyntax側での変更をswift-format側にも対応してくれてるのでまだ平和に進んでますが、他のSwiftSyntax使ってるツールはそんな手段は取れないので大変ですね...

5.9のリリース後はある程度落ち着くとは思うけどそれは頻度の問題で大変なのはあまり変わらないでしょうね。

1:52 AM

とりあえずテストをたくさん書いて、SwiftSyntaxとToolchainのアップデートを自動でPR出すように整えるのが最低限必要かな。

https://github.com/apple/swift-syntax/pull/2050 ^ これは私が欲しかったやつ。とてもいい。次のように書けるようになる。

#if canImport(SwiftSyntax510) // code specific to swift-syntax version >= 510 #elseif canImport(SwiftSyntax509) // code to support swift-syntax version 509 #else // code for swift-syntax < 509. Not needed for macros since macros require swift-syntax >= 509. #endif

Add a version indicator macro to indicate the swift-syntax version ...

All swift-syntax versions ≥ 509 will include a module SwiftSyntax509 and all swift-syntax versions ≥ 510 will include both SwiftSyntax509 and SwiftSyntax510. This way clients can check which versio...

おお・・・　モジュール名が変わるようになったのか

12:51 AM

大本の SwiftSyntax の定義はどうなってるんだ？

12:52 AM

SwiftSyntax509は空っぽのモジュールなのか

12:53 AM

ライブラリがSwiftSyntaxに入ってるのは同じなんですね　なるほど

12:53 AM

こんな方法があったのか

12:53 AM

いや、普通のSwiftPMライブラリではこの技は使えないよな

12:53 AM

dependencyのところにSwiftSyntax509って書かないといけない

SwiftSyntax v509.0には509のダミーモジュールがあって、v510.0は510のダミーモジュールになる、ってことですよね。

canImportはswiftpmとは違う仕組みでビルドされてるときしか使えなそうだな

環境によってバージョンが上がるライブラリについては有効と。

なるほどなあ

メンテナンスの大変さは依然としてあるんだけど、これがマージされると

 override func visit(_ node: IdentifierExprSyntax) -> ExprSyntax { if case .binaryOperator = node.identifier.tokenKind { return super.visit(node) } guard let parent = node.parent, parent.syntaxNodeType != FunctionCallExprSyntax.self else { return super.visit(node) } #if canImport(SwiftSyntax509) if let parent = node.parent, let memberAccess = parent.as(MemberAccessExprSyntax.self), memberAccess.declName == node { return super.visit(node) } if let parent = node.parent, parent.syntaxNodeType == KeyPathPropertyComponentSyntax.self { return super.visit(node) } #endif let column = graphemeColumn(node) return apply(ExprSyntax(super.visit(node)), column: column) }

のように書けるところは差分で書けるようになってわかりやすくなるはず。

12:56 AM

^ の例はこの間の構造の変更に対応したやつ。

そうですね　これはでかい　無理だと思ってました

12:57 AM

ライブラリ側はワンソースで保守できますね、ブランチわけたりしなくてよい

#ifだからトップレベルにも書けるのでVisitorの関数をオーバーライドする・しないもいけるはずだからかなりいい。

https://forums.swift.org/t/gsoc-2023-my-gsoc-experience/67340

[GSoC 2023] My GSoC Experience

Hey all! I am excited to share with you about what I have done with my mentor @ahoppen in this year’s GSoC project. In the past few months, I mainly worked on implementing incremental parsing for SwiftParser. The goal is to make SwiftParser parse source files incrementally when we are in some special contexts like syntax highlighting. We aims ...

1:49 PM

SwiftSyntaxのインクリメンタルパーサ開発の報告

1:50 PM

1:51 PM

このコードでswitch xを消すと、関数呼び出し+ラベル+文だったのが、第二後置クロージャ付きの一つの関数呼び出しに変化するのエグいw

1

1:52 PM

To solve the problem above, we collect some additional information for every syntax node we parsed in the initial parse to mark the possibly influence range for each node and use that information to help us parse correctly when execute incremental parsing.

1:53 PM

あるノードに属する部分テキストを編集したときに、どの範囲までパースをやり直せば良いか、の情報を用意するようにした、のかな

1:58 PM

その範囲を判断するの文法に依存した非自明な手続きに思えるけどどうやってんだろ

https://github.com/apple/swift-syntax/pull/1685/files うーん、 registerNodeForIncrementalParse がミソっぽいけどよくわからない top levelのcode block itemと、declのmember block itemのパース単位で、開始トークンの位置を記録してる？っぽいけど、どうやって問題のケースで巻き戻ってるんだろ

Port incremental parsing ability to CodeBlockItem by StevenWong12...

I want to make this pr as a start effort to port incremental parsing ability to SwiftParser.

マクロに、マクロを展開して生まれた型に対してソースコードの定義元を定義したいんですけど、そういうインターフェースってありますかね？

@defineFoo() // 3. ここに飛んでしまう。`var aaa`に飛ばしたい struct S { var aaa: Int var aaaFoo: Int // 1. マクロで生えた } S().aaaFoo // 2. 使用箇所。ここでaaaFooにカーソル合わせて定義ジャンプする

(edited)

.package( url: "https://github.com/apple/swift-syntax", "508.0.0"..<"510.0.0" ) SwiftSyntaxへの依存は範囲で書く、っていうのはその通りっぽいな。これからそうしよう。 https://www.pointfree.co/blog/posts/116-being-a-good-citizen-in-the-land-of-swiftsyntax

Being a good citizen in the land of SwiftSyntax

How can you be a good citizen in the new world of SwiftSyntax proliferation? Follow our advice to keep the greater Swift ecosystem healthy and thriving.

2

これって#ifで1つのコードで複数バージョンのSwiftSyntaxをサポートする前提だから、単に辛そうですね

1:27 PM

あ、SwiftSyntaxのバージョンが上がる分には警告だらけになるけどエラーにはなりにくいから、サポートしてなくても最新まで上げとくと助かる人もいるか

しんどいのはそう。各マクロでSwiftSyntax抱えたほうがマシっていうのと比較して良くなったっていう感じかなあ。508 => 509ほどの変更がなければ、って前提もある。

これをやる場合って (swift-syntax に依存する) ライブラリ作者は swift-syntax が 508.0.0 で依存解決された場合のテストと 509.0.0 で解決された場合のテストと 510.0.0 で解決された場合のテストをそれぞれ CI で走らせることになるんですかね？それをやろうと思ったらテストターゲットだけ別パッケージに切り出すか，あるいは Package.resolved を動的にいじってテストを走らせることになりそうですが... (edited)

ちゃんと毎回テストするのはそんな感じの工夫がいりそうですね。簡単にするなら下のバージョンについてはそれまでにテストされてるから最新でテストしてOKならOKとして考えてもいい気がします。 (edited)

新規に追加するコードは全部 #if で新しいバージョンでしかコンパイルされないようにして，既存コードを一切書き換えない前提ならそれもありですね．

内容によるのはそうですね。問題はあまり解決してないけど、これまでは複数バージョンの対応を諦めるか、509用のバージョン、510用のバージョンみたいに分けるか、SwiftSyntaxを抱え込むか、みたいな大げさな選択肢しかなかったけど #if canImport(SwiftSyntax509) と分岐できるようになって最小限で済むようになったのがちょっと前進、みたいな。

1

うちの新卒が書いてくれました。よいです https://zenn.dev/oks/articles/2dcd28a22d4ba6

swift-syntaxを用いて、簡単なコマンドラインツールを作ってみる

3

https://forums.swift.org/t/is-there-a-way-to-programmatically-allow-trust-the-compiler-plugin-to-run-from-the-command-line/65690/4 マクロをTrustしないでいいやり方はコンパイラオプションで-skipMacroValidationという方法もあるみたい。

Is there a way to programmatically allow (trust) the compiler plugi...

Is there a way to explicitly set a specific list of macros that are validated instead of skipping validation for all of them? as the documentation of the option suggests this is a security risk: -skipMacroValidation Skip validation of macros (this can be a security risk if they are not from trusted sources)

Paul Hudsonさんと少し話してマクロはSwiftSyntaxより上位の抽象度が高いマクロ用APIが必要だよね、ってところで同意できた。やっぱりそうだよね。

僕も今仕事のコードでちょっとしたマクロにしたい部分あるのでやってみたいなあ多分同じ気持ちになりそうな気がしてる (edited)

2:06 PM

ところで、@availabilityはまだしも、#ifの入れ子とかありえるのエグいですね

そうだねえ。確か#ifをコンパイラが扱うように扱えるライブラリがSwiftSyntaxの中に作られてたけどあれの進捗どうなったかな。

2:22 PM

https://github.com/apple/swift-syntax/pull/1816 これだ。Openのままだ。

SwiftIfConfig: A library to evaluate #if conditionals within a Sw...

Swift provides the ability to conditionally compile parts of a source file based on various built-time conditions, including information about the target (operating system, processor architecture, ...

あー、演算子のやつみたいに、マクロ処理前に評価して分岐を消しちゃえばいいんすね。

こういうのが増えるのはだいぶいいんだけど、やっぱりコンパイラが求めてるものとマクロで必要なものはちょっと違うねんな。

そうですね。

2:37 PM

PropertyWrapperは制限もあるけどちゃんと作れるのに対して

2:38 PM

マクロは制限は少ないけど壊れないように作るのもそもそも難しい

2:38 PM

なんかその間ぐらいのメンタルモデルでやりたいですよね

今ならいい感じのが作れる気はちょっとする。前にやろうとしたときはSwiftSyntaxがどんどん変わるから諦めた。

Triviaのパースルールの説明書って今どこに行っちゃったんだ？

11:33 PM

https://swiftpackageindex.com/apple/swift-syntax/510.0.1/documentation/swiftsyntax 検索したけどわからん

libSyntaxに書かれてたものはlibSyntaxの依存が消えたときに消えた。

Discord検索、最高〜 > https://discord.com/channels/291054398077927425/561853152408895518/1060462539269488660 (edited)

Kishikawa Katsumi

libSyntaxに書かれてたものはlibSyntaxの依存が消えたときに消えた。

これ普通に消えたんですね・・・ https://github.com/apple/swift/blob/980d40951ff557047dce833d1d092b400bbc20db/lib/Syntax/README.md

swift/lib/Syntax/README.md at 980d40951ff557047dce833d1d092b400bbc2...

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

私も問題あると思ってたんよね。

11:37 PM

https://github.com/apple/swift-syntax/issues/438 この辺りの議論が検索に引っかかって辿れたりする。

[SR-9616] SwiftSyntax is not following trivia rule · Issue #438 · a...

Previous ID SR-9616 Radar None Original Reporter inamiy (JIRA User) Type Bug Attachment: Download Environment Apple Swift version 4.2.1 (swiftlang-1000.11.42 clang-1000.11.45.1) SwiftSyntax 0.40200...

Kishikawa Katsumi

私も問題あると思ってたんよね。

Swift Syntaxを使う上でこのtrivia ruleがわかんないとやりづらいと思うんすよねえ

めっちゃ困ると思う。フォーマッタとかどこにインデントやスペースが入るのかわからないと統一的に書けないしね。

まあ、AST Explorerでtriviaどうなるか見てみたら、ふーんいけんじゃん、ってなりそうではあるけど、個人的には先にお勉強から入りたい。

1. A token owns all of its trailing trivia up to, but not including, the next newline character. 2. Looking backward in the text, a token owns all of the leading trivia up to and including the first newline character. 1. Trailing Triviaは改行の手前までのTriviaが付く 2. Leading Triviaは連続する改行が途切れるまでのTriviaが付くルール知らずに結果だけ見て法則を見つけるのはけっこう難しいと思うねん。

英語じゃなければプルリク作るんだけどな〜

Kishikawa Katsumi

1. A token owns all of its trailing trivia up to, but not including, the next newline character. 2. Looking backward in the text, a token owns all of the leading trivia up to and including the first newline character. 1. Trailing Triviaは改行の手前までのTriviaが付く 2. Leading Triviaは連続する改行が途切れるまでのTriviaが付くルール知らずに結果だけ見て法則を見つけるのはけっこう難しいと思うねん。

確かに最初の改行までは前のトークンのtrailingになるところは言われないとわからんかも

図にするとこう。ルール知らないと波カッコの位置を整形する処理をうまく書くの難しい。

ドキュメントについてはもちろんPR歓迎ですが、そうでなければとりあえす github issue 立てていただけるとありがたいです。 (edited)

1

issue立ててくるか

1

Kishikawa Katsumi

図にするとこう。ルール知らないと波カッコの位置を整形する処理をうまく書くの難しい。

iOSDCの時の資料ですっけ？色がついててわかりやすいですね。波括弧は確かに！

立てた https://github.com/apple/swift-syntax/issues/2582

Request for Documentation on Parsing Rules for Trivia in swift-synt...

Description I'd like to request documentation on the rules for parsing Trivia. There used to be documentation explaining the rules for parsing Trivia back when we were using libSyntax, but it s...

2

Triviaのつき方を可視化できるようにしてみた。これに加えてポップオーバーで情報を提供すれば便利な気がする。

おお、いいですね。

ありがとう。

おもしろい

これとルールを一緒に表示したらパッと理解できると思う。

とりまこんな感じやろ。たぶんわかりやすい。

おお

ちなみに trivia のパースルールで通常のルールに従ってないところがあって、 let str = """ foo bar """ 複数行文字列リテラル内部開始""" の改行はその trailing trivia になり、また各行の改行は trivia ではなくトークンの一部としてパースされます。(リテラル内部最終行を除く) (edited)

おおー

10:55 PM

10:57 PM

テキスト行の改行についてはトークンの中身を繋げたら文字列コンテンツが復元できて欲しいからそれで嬉しい気がする (edited)

10:58 PM

開始トリプルクォートの後ろの改行は、どっちについててもそんなに影響ないかなあ

10:59 PM

あ、そうか、ここはコメントが書けないんだ

10:59 PM

むむ

11:00 PM

コンパイラだとシンタックスエラーっぽいけどSwiftSyntaxだけだと許される入力だ？ (edited)

11:01 PM

どうなんだろうこれ textSegment("/**/\n") じゃなくて

11:01 PM

/**/\n がトリプルクォートのtrailing triviaでも良い気がする

11:02 PM

いや swift-syntax的には unexpected token になるのが良いのか

11:04 PM

これも似たような感じだ (edited)

11:04 PM

missing leading trivia " " って感じだけどそんな概念はないかｗ

rintaro@rintaro-m1macbookpro swift-syntax % ./.build/debug/swift-parser-cli print-diags test.swift === test.swift:2 === 1 │ 2 │ let str = """/* foo */ │ ╰─ error: multi-line string literal content must begin on a new line 3 │ foo 4 │

なんで、ParserDiagnosticsではじかれる感じですね

あんまり意識してなかったステージだ

複数行文字列リテラルってそんな構造やったんか。複雑やな。

. @S_Shimotori さんが僕が昔書いたSwiftSyntax5.1のコードをSwiftSyntax5.10にマイグレートしてくれたんだけどまあまあエグかったｗ https://github.com/omochi/SwiftTypeInferenceHandsOn/pull/19/files

ParameterClauseSyntaxをrenamedメッセージに従ってFunctionParameterClauseSyntaxにしたら間違い（closureを扱いたいのでClosureParameterClauseSyntaxが正解）で一瞬ハマりましたがなんとかなってよかったです。

なるほど。同じものだったのが2つに分かれたのか。 (edited)

Kishikawa Katsumi

.package( url: "https://github.com/apple/swift-syntax", "508.0.0"..<"510.0.0" ) SwiftSyntaxへの依存は範囲で書く、っていうのはその通りっぽいな。これからそうしよう。 https://www.pointfree.co/blog/posts/116-being-a-good-citizen-in-the-land-of-swiftsyntax

こういう方法で swift-syntax のバージョン制約を範囲で書いている場合，今って最新リリースの 510.0.2 じゃなくて 600.0.0-prerelease-20YY-MM-DD みたいなバージョンで解決されちゃうので微妙ですね．あんまり良くなかったのかもしれません． (edited)

510で上を押さえているのに、どうして600に解決されるんですか？

@omochimetaru 記事が書かれた当時が 510 だっただけであって，あそこで書かれているのは 下限 ..< 現在リリースされている最新版から 2 個先のメジャーバージョン という認識です． (edited)

2:32 PM

When version 510 of the library is finally released, you should update your library to support a larger range of SwiftSyntax versions. If you currently support version 508, then you would update like so:

なるほど。508と509をサポートするために <510 で押さえたら、 510 のマイナス付きバージョンが含まれてしまうのか。 (edited)

2:34 PM

そうすると 508.0.0 ..< 509.999 みたいな書き方がいいのか・・・？ (edited)

すみません，勘違いしてました．改めて読んでいたら最新版の 1 こ次のメジャーバージョンを書くので今は ..<"600.0.0" になっているはずですね．だとしたら問題なかったです．問題を混同してました．600.0.0 の prerelease が降ってきてしまうのは直接 swift-syntax に依存している場合じゃなくて swift-testing 経由で間接的に依存している場合でした．これは意図してそうなっているので問題なかったですね． https://github.com/apple/swift-testing/blob/0.8.0/Package.swift#L36 (edited)

..<600.0.0 に対して 600.0.0-beta とかはマッチしませんでしたっけ？ x-beta < x だから

しないみたいです．

1

Version の < の実装を読むと普通にマッチしそうに見えますが，実際に試してみると "510.0.0"..<"600.0.0" でも "510.0.0"..<"600.0.0-latest" でも "510.0.0"..<"600.0.1" でもマッチしなくて，"510.0.0"..<"600.0.1-latest" でようやくマッチしますね． https://github.com/apple/swift-package-manager/blob/4a6660ac95f4b2f88e1006f84576b0ca16343eb9/Sources/PackageDescription/Version.swift#L121

1

3:07 PM

"510.0.0"..<"600.0.1" だとマッチしなくて "510.0.0-latest"..<"600.0.1" だとマッチしますね．なんかバージョン比較のロジックに欠陥があるように見えます．

とりあえずこの 4 つは全部 true だったんで，Range<Version> 自体は問題なくて，何か SwiftPM が余計なことをしてそうですね．

assert(Version("600.0.0-beta") < Version("600.0.0")) assert(Version("510.0.0") <= Version("600.0.0-beta")) assert((Version("510.0.0")..<Version("600.0.0")).contains(Version("600.0.0-beta"))) assert((Version("510.0.0")..<Version("600.0.0")).contains(Version("600.0.0-prerelease-2024-05-07")))

一部で TSC の Version が使われていたんでそっちも覗いてみたら，こいつが犯人っぽいですね．なぜこんなルールにしたのだろうか... https://github.com/apple/swift-tools-support-core/blob/b170d46b94d6c1cd91db97d2e3a1e0bdb5b79a24/Sources/TSCUtility/Version.swift#L347-L360 (edited)

blame していったら経緯がありました．prerelease バージョンをフェッチするかどうかは opt-in になっていて，バージョン制約に prerelease が現れたら初めてフェッチする対象に含まれるんですね． https://github.com/apple/swift-package-manager/issues/4996 https://github.com/apple/swift/issues/43651 (edited)

[SR-5192] swiftpm 4 incorrectly resolves prerelease major version a...

Previous ID SR-5192 Radar None Original Reporter @sharplet Type Bug Status Resolved Resolution Duplicate Environment % swift --version Apple Swift version 4.0 (swiftlang-900.0.43 clang-900.0.22.8) ...

[SR-1039] Fetch a dependency with a specified Pre-release version ·...

Previous ID SR-1039 Radar rdar://problem/31214600 Original Reporter kkoval (JIRA User) Type Bug Status Resolved Resolution Done Additional Detail from JIRA Votes 0 Component/s Package Manager Label...

プレリリースバージョンへの依存をうまく書けなくて困った覚えがある。

この辺で書かれていらっしゃったときですかね https://github.com/apple/swift-package-manager/pull/223#issuecomment-218635403 (edited)

たぶんそう

SwiftSyntax 600.0.0でなんか非互換があるかなと思ったけど特になく平和に済みそうなのかな。

ですね．お騒がせしました

あ、いやkeboさんの書き込みに何か言いたかったわけではなく、単に今度のメジャーバージョンアップの際にはなにごともなさそうなのかなと。私が観測してる限りは大丈夫そうだけどなんかあったりするかも、みたいな。

1

https://forums.swift.org/t/swiftifconfig-library-for-handling-if-clauses/73004

SwiftIfConfig library for handling #if clauses

Hi all, Swift has #if to affect to allow different build configurations to impact what code is part of the final program. The conditions in #if are a simplified form of the Swift expression syntax, so you can have code like this: #if DEBUG #if compiler(>=5.7) && hasFeature(ParameterPacks) func f(_ args: repeat each Arg) { } #endif #else ...

2:51 AM

#if を評価するミニライブラリ

SwiftLintが0.56.0からswift-syntaxの600.0.0-prerelease-2024-07-24を使うようになってて、クロスビルド(mainツールチェインで5.10ツールチェイン同梱sdkを使う)しようとすると、-swift-version 6が5.10ツールチェインへ渡されるようになってビルドが失敗する。

7:22 AM

5.10ツールチェインを含むsdkの定義でcliオプションとして-swift-version 5を渡すように設定すればビルドは通るのだけど、swift-syntaxのソースを見ても、どうして-swift-version 6が使われるのかが分からない。

7:25 AM

あいや、これか。 https://github.com/swiftlang/swift-syntax/blob/06b5cdc432e93b60e3bdf53aff2857c6b312991a/Package.swift#L336C16-L336C23

swiftLanguageVersions: [.v5, .version("6")]

リリース前のタグに依存してリリースしてしまうのは、なかなかな威勢がいいな。

多分ですがそこは関係ない気がします．デフォルト挙動が -swift-version 6 になるのは swift-tools-version: 6.0 以上に設定されている時だけだったはずで，swift-syntax の swift-tools-version は 5.7 で他の Package@*.swift も無いので．そうなると，Swift SDK を使っている場合特有の問題なのか，ビルドする際の他のフラグだとかが原因だったりしないかというのが気になりますね． https://github.com/swiftlang/swift-package-manager/pull/7469

それかここでいうデフォルト挙動というのは swiftLanguageModes (swiftLanguageVersions) がない場合だけを指していたか

むむ、バグなのか。もうちょっと調べてみるか。

Swift SDKを使わなくても、Xcode 16 beta 5で普通にSwiftLint 0.56.1をビルドしただけで、swift-syntaxのビルドに-swift-version 6が使われるな。

見た感じswift-syntax関連は全部-swift-version 6でビルドされてる。

$ yq -P '.commands|with_entries(select(.value.args|join(" ")|contains("-swift-version 6")))|keys' .build/debug.yaml>commands-built-with-swift-version-6.yml

commands-built-with-swift-version-6.yml

2.33 KB

SwiftSyntaxBuilderを使ったコード生成を試してるけど、ある部分に何の型を使うべきかがわからなくて難しいな

4:03 AM

InheritanceClauseSyntax の中にとりあえず TypeSyntax を書いたけどエラーになって、 InheritedTypeSyntax が正解だった

4:10 AM

あと全部trailingクロージャでかくと何か間違えた時上の方で変なエラーになってしまってどこが悪かったのかわからないからラベル付けたくなる (edited)

SwiftSyntaxBuilderは分岐やループが必要なときに便利ですが、そうでない単一の式を書く場合は通常のinitのほうが便利なイメージですね

空行の位置とか気になってきて、文字列で生成してから丸ごとフォーマットしたほうが楽かもという気がしてきた

空行とかインデントの調整むずいんですよね

4:27 AM

文字列使うと若干マクロ実行パフォーマンスが落ちる気もしています

4:27 AM

バリデーションが挟まってる

Xcode AI補完がめっちゃ補完してくれるけどほぼ嘘でしんどいｗ

2

SwiftBasicFormat に indentationOfLine があって便利だ

多段に var を掘って　書き換えて組み立て直すのが大変だ

7:48 AM

ローカル inout バインディングが欲しい

 elements.append( ArrayElementSyntax( leadingTrivia: [.newlines(1), .spaces(indent)], expression: ExprSyntax("\(raw: urlTypeName).self") ) )

1:17 PM

 members.insert( MemberBlockItemSyntax( leadingTrivia: [.newlines(1), .spaces(indent)], decl: DeclSyntax( "public var \(raw: varName): FrontPageEntry" ) ), at: insertIndex )

1:17 PM

このパターン、うまく行くのたまたまか・・・？

1:17 PM

SyntaxBuilderのinitは leading trivia が取れなくて、 interpolateで埋めることはできるけど、綺麗に書けない

1:18 PM

だけどたまたまそれをラップするArrayElementとかMemberBlockItemがあるから、そこのinitでうまいことleadingTriviaが刺せる

1:18 PM

Collection系はだいたい専用のItem Node が一回ラップしてるから、だいたいこの形でうまくいくのかな

InitializerDeclSyntaxのbodyにstatementを追加しようとしてるけど

1:18 AM

色々試してもleading triviaが無視されて改行が挿入できない・・・なんだ・・・？

1:22 AM

あ〜〜〜〜

1:22 AM

わかるかも・・・・

1:23 AM

あーいけたわ

1:23 AM

代入文を作りたかったので、StmtSyntax を構成してたけど

1:23 AM

let のついてないただの代入文は expr が正解なんだ

1:24 AM

それを間違えてるから MissingStmtSyntax が内部的に構成されて挙動が変？になってた (edited)

1:24 AM

ExprSyntaxにしたら思った挙動になった

1:26 AM

missing stmt syntaxはsource visibleじゃないから多分そこにくっついたtriviaが構成するときにnodeごと消えた

自前のサーバサイドエンジンに、ウェブ画面を追加するときに色々ボイラープレート作業が生じるやつを、swift-syntaxのコード編集で自動でやるようにしてみたけど、慣れたら結構サクサクできた (edited)

3:02 AM

.indentationOfLine, .trimmedDescription, BasicFormat(initialIndentation:) などの

3:02 AM

ちょっとしたユーティリティが思ったより充実してて良かった

3:03 AM

SyntaxRewriter をオーバライドして関数ローカルに実装するときに、selfをキャプチャさせるためにinitとletをそのクラスに実装する部分が一番めんどくさかった

3:04 AM

Javaだったら内部クラスは暗黙にオーナーをキャプチャしてくれるから楽なんだけど

3:04 AM

Swiftはそれがないのがな

3:06 AM

全部クロージャでセットアップできるRewriterインターフェースがあっても良さそうだけど、visitメソッドのオーバーロード多すぎてしんどい予感しかない

関数ボディ内部型で ~Escapable 宣言すると外の値を参照出来るようになれば便利かもしれないですね。今は class は ~Escapable サポート対象外なので SyntaxRewriter は難しそうですが。 (edited)

なるほど。でもクロージャーだったら特に何もしなくても外の値をキャプチャしつつescapeすることができるので、escapeしない場合だけサポートというのは不自然にも感じます。

シンプルに全ての実装をクロージャプロパティに持った ClosureSyntaxRewriter があったら便利かなと考えたんですが、 (edited)

4:53 AM

visitメソッドの種類に対応するプロパティが200個ぐらいあるのでinitのシグネチャがでかくなりすぎて (edited)

4:53 AM

あまり良くないですよねえ。

クロージャをプロパティに持つんであれば initですべてを突っ込む必要はないので大丈夫かとは思いますが

4:57 AM

クロージャがescapingになってしまうのでうれしさ半減じゃないです？

あーなるほどそもそもこれがあるので外側をclassにしてて気にしてなかったですけど

4:58 AM

制御フロー的にはnon escapingに寄せられそうですね

let rewritten = node.rewrite( funcDeclSyntax: { node in .. .} tokenSyntax: { token in ... } ) みたいなのだったらnonescapingでいいんだろうけど、200+ のdefaulted引数きついな笑 (edited)

その形式使いやすくていいですね僕のユースケースだと大体の場合はメソッド一個しかoverrideしないで終わるので、引数一個のrewriteを200種類用意するのでも十分そう・・・

5:02 AM

特定の箇所に潜るとき、 (1) struct定義見つけて、 (2) init定義見つけて、みたいにやるけど、これも状態管理するとややこしいから2つのrewriterに分けちゃいたい (edited)

1

こんな計画が進んでいるんですね

a new swift-syntax library: SwiftLexicalLookup. the library implements a new unqualified lookup API, which aims to replace the current ASTScope implementation in the long run. https://forums.swift.org/t/gsoc-2024-swiftlexicallookup-a-new-lexical-name-lookup-library/75889

[GSoC-2024] SwiftLexicalLookup - a new lexical name lookup library

Hi everyone, I'm Jakub, and this summer during GSoC, I've worked with @Douglas_Gregor on a new swift-syntax library: SwiftLexicalLookup. It consists of various lexical queries, answering questions like "Where is an error thrown here handled?" or "Which switch cases does this fallthrough keyword refer to?". Most importantly though, the library i...

FunctionParameterSyntaxにはstring interpolationがあるのにLabeledExprSyntaxにはないのはどういうルールなんだ？

1:40 AM

ExprSyntaxでまとめてあるのか

1:42 AM

LabeledExprSyntaxはExprSyntaxじゃないな

1:45 AM

関数呼び出しを組み立てるのに foo: bar の配列を作りたいけど

1

1:45 AM

楽な方法が微妙にない

Parseじゃない部分の機能は結構まだまだって印象ある。構築の方は去年バグもそこそこ見つけたし。PR出したらいいんじゃないだろうか。

ふむ。設計意図じゃなくて単に不便なだけかもしれないか。

1:49 AM

正解もわからんしPRより要望を投げるのがいいかも。

Syntaxを組み立てる方の機能はマクロでめっちゃ需要増えたけどそれまではほとんどなかったと思うんよね。

確かに

1:57 AM

あーでもわかってきたぞ

1:57 AM

FooSyntax: SyntaxParseableと parser.parseFoo が対応してんのか

1:58 AM

LabeledExprSyntax もこれは対応を追加できそうだ。

1:59 AM

試しに実装したいけどinternalだからめんどいな・・・

最近SwiftSyntaxを使ってEncodableのようなものとDecodableのようなものを自動実装してみたんだけど

12:35 PM

プロパティの型があるプロトコルを満たすか、とか、ある型かどうか、という判定が書けないから、SwiftのCodableと同レベルの品質にはできない事に気がついた

1

12:36 PM

Stringかどうかとかは単純には書けるけど、typealiasされてたらわからなくなる

12:37 PM

ただ実用的には困らないケースだったので、CodableのDecoderを実装するよりシンプルになってよかった

こういう方向性のやつということですか？ https://github.com/SwiftyLab/MetaCodable

GitHub - SwiftyLab/MetaCodable: Supercharge Swift's Codable impleme...

Supercharge Swift's Codable implementations with macros meta-programming. - SwiftyLab/MetaCodable

これはCodable本体はそのままでプロパティに手を入れるやつじゃないっすか？

1:19 PM

僕がやったのはSwift.Codableとは全く関係ないです

ああ，やっぱりそうなのですね．{En,De}codable protocol を実装させるわけじゃなくて完全独自のエンコード・デコード API を生成しているということですかね？ (edited)

1

特定の規格のXMLドキュメントを型付けしたくて、(jsonを意識してる)Codableだとうまくハマるかわからなかったので、完全に自前で組みました (edited)

私の場合は，以前スキーマが決まっている XML のエンコード・デコードを実装した時は，Codable ベースの XMLCoder というサードパーティライブラリ (元々 Max さんが作っていたやつ) でうまくはまりましたね．

MacroがSwiftSyntaxを使っているときにSPMがビルド済みのSwiftSyntaxを勝手に導入してくれる機能（？）が入りそう。 https://github.com/swiftlang/swift-package-manager/pull/8142

Add support for a prebuilt swift-syntax library for macros by dscha...

Following the pattern used for the early Traits work, added a workspace prebuilts manager to co-ordinate detecting when macros are using swift-syntax, downloading the zip file for the resolved swif...

2:25 PM

このissueを追ってたら発見 https://github.com/swiftlang/swift-syntax/issues/2421 (edited)

prebuilt swift syntax、実現するのか。 (edited)

2:33 PM

There are many folks who've already demonstrated a fix (see InstantSyntax, BinarySwiftSyntax etc.) and the only reason

↑このスレッド、僕も、バイナリ配布ニキとして言及されてるんですよね

1

最近Macroを書くようになったんですが、標準のSwift SyntaxのAPIだけだとコードをパースするのが難しくて、必要に応じてstoredPropertyの一覧を取るメソッドとかの各種Extensionを毎回書かないとコードがめちゃくちゃ煩雑になってしまい、最初から使いやすいヘルパーみたいなものがほしいと思ってしまう (edited)

わかる。そういうの作ってるひと2人くらいいたけどどうなってるかな。

わかる。syntacticなデータ構造なので必要な関心の粒度にフィットしてないんですよね。僕もマクロとかの用途では都度作ってます。 ↓これはそれをもっと強力にやったやつ https://github.com/omochi/SwiftTypeReader

GitHub - omochi/SwiftTypeReader: You can gather type definitions fr...

You can gather type definitions from Swift source code. - omochi/SwiftTypeReader

https://github.com/stackotter/swift-macro-toolkit これとかね。

GitHub - stackotter/swift-macro-toolkit: A powerful toolkit for cre...

A powerful toolkit for creating concise and expressive Swift macros - stackotter/swift-macro-toolkit

スタックオッターさんだ。

12:35 AM

guard case let .simple("Result", (successType, failureType))? = destructure(returnType) else { throw MacroError("Invalid return type") }

12:35 AM

このAPIデザインはいいですね。

12:35 AM

SwiftSyntaxの型ってめっちゃたくさんメソッドやプロパティが生えてるから、拡張しちゃうと粒度が揃わなくて紛れて意味不明になっちゃうなと思ってて。 (edited)

1

12:36 AM

これだったらトップレベル関数で抑えるスタイルだから、そのまま触る場合と便利レイヤーから触る場合を明確に区別できそう。

うん。インターフェースはとてもいいと思う。あとそれぞれのコードも読みやすく書かれてるから、これを挟むことでかえってよくわからなくなる、ってこともないと思う。

1

このパターンマッチの形式初めて見ました。こういう使い方もできるのか。

おー便利そうなやつだ。ありがとうございます

https://github.com/swiftlang/swift-syntax/pull/2925

[Syntax] Use BumpPtrAllocator for Syntax node internals by rintaro ...

Rework Syntax internals. "Red" tree is now bump-pointer allocated and visited children are cached. Syntax is a pair of the allocator (strong reference to SyntaxDataArena class) ...

4:37 PM

りんたろーさんがなんか面白い事してる特定のケースでパフォーマンスがかなり上がってる

4:40 PM

Green treeはイミュータブルデータ構造だから、その裏のRed treeはgreenの生成時にスナップショット的に管理できて、それをバンプアロケートしつつARCオーバーヘッドを減らすって感じか・・・？

良い変更だと思いますが，これによって pthread 必須になってしまったため，wasm32-unknown-wasi みたいな pthread 互換の API がないターゲット向けに swift-syntax をビルドすることができなくなってしまって，どう対処するのが良いんだろうなと考えてます． (edited)

実際にはスレッドが実行されることがないのだから、pthread風の何もしない実装を注入するのが良いんじゃないでしょうか

非マルチスレッド環境向けなら、ここに #elif で空のPlatformMutex実装をつっこんでいただければ良いかなと思います。それか threads.h ありな環境なら #elif __has_include(<threads.h>) で mtx_t での実装もありかも https://github.com/swiftlang/swift-syntax/blob/56a746db8ffb4f864f6df82993bf46f47f95b766/Sources/_SwiftSyntaxCShims/PlatformMutex.c#L83-L85

swift-syntax/Sources/_SwiftSyntaxCShims/PlatformMutex.c at 56a746db...

A set of Swift libraries for parsing, inspecting, generating, and transforming Swift source code. - swiftlang/swift-syntax

非マルチスレッド環境向けなら、ここに #elif で空のPlatformMutex実装をつっこんでいただければ良いかなと思います。

ありがとうございます．ですね．方針自体はそうなると思います．

よくわからんけどswift-syntaxのバイナリ配布がもう少しで実現されそう

Waiting for a last minute bug fix to be release with 6.1.1. Soon :).

https://github.com/swiftlang/swift-syntax/issues/2421#issuecomment-2855073378

Distribute a prebuilt swift-syntax binary · Issue #2421 · swiftla...

Description I think that it'd be great to also distribute swift-syntax as a prebuilt framework with every release, at least for Apple platforms (like https://github.com/realm/SwiftLint does). W...

4

1

2:26 AM

これは関係あるんだろうか・・・？ https://forums.swift.org/t/se-0482-binary-static-library-dependencies/79634

SE-0482: Binary Static Library Dependencies

Hi folks, The review of "SE-0482: Binary Static Library Dependencies" begins now and runs through 15 May 2025. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager. When emailing the review mana...

https://forums.swift.org/t/preview-swift-syntax-prebuilts-for-macros/80202

[Preview] Swift-Syntax Prebuilts for Macros

The introduction of macros to Swift has given developers the ability to create more expressive libraries that can be distributed as a Swift package. Macros can greatly improve the developer ergonomics making Swift packages an even more appealing environment in which to work. One issue developers run into when adding dependencies on these packag...

5:00 PM

swiftsyntaxのバイナリ配布が始まったフラグをつけるとバイナリを取りに行くらしい

5:00 PM

Xcode16.4にも隠しフラグがあって使えるらしい

なんか上手くいかないなと思ってたら，main や 6.2 の snapshot ツールチェーン向けにはまだ配布されていないんですね．6.1.2 を使ったらダウンロードが始まりました．そして，リリース版のツールチェーンであるにも関わらずリリース版のツールチェーンでは本来使用が封じられているはずの experimental な code item macro が普通にコンパイル通っちゃいました．個人的にはラッキーですがいいんだろうかこれは...

5:56 PM

いや，code item macro のコンパイルが通っちゃうのは swift-syntax をソースからビルドした場合も一緒でした．なので 6.1.2 ツールチェーン側の問題っぽいです．(リリース版だというフラグがオンになってなさそう)

あれ，6.1.2 だけじゃなくて 6.1.1 でも 6.1.0 でもビルドが通ってしまった... (AvailableInProd が false な機能なのに...)

Linux の 6.1.2 だとちゃんとビルド失敗してくれるので，macOS のツールチェーンだけの問題みたいでした．とりあえず swift-syntax に関係なかったことがわかったのでこの辺で失礼しておきます．

It is also available in Xcode 16.4 by enabling a user default. defaults write com.apple.dt.Xcode IDEPackageEnablePrebuilts YES

16.4 RCの時にフラグ経由で使えてたのは確認してたけどちゃんとXcodeでも使えるんですね。

これバイナリを提供する側はどこに何を宣言するんだろ

https://github.com/swiftlang/swift-package-manager/pull/8214/files

Swift-Syntax Prebuilts for Macros 6.1 by dschaefer2 · Pull Request...

Following the pattern used for the early Traits work, added a workspace prebuilts manager to co-ordinate detecting when macros are using swift-syntax, downloading the zip file for the resolved swif...

10:29 PM

https://github.com/swiftlang/swift-package-manager/blob/main/Sources/swift-build-prebuilts/BuildPrebuilts.swift

swift-package-manager/Sources/swift-build-prebuilts/BuildPrebuilts....

The Package Manager for the Swift Programming Language - swiftlang/swift-package-manager

10:29 PM

なんかここにハードコードがあるな

10:29 PM

これは事前ビルドをする側か？

[quote="dschaefer2, post:13, topic:80202"] This is only used for macro targets. The prebuilt library itself is not used in the product code. And artifacts are signed to allow SwiftPM to ensure they are what was published. [/quote]

10:41 PM

そもそもマクロだけの話なのか

SwiftSyntaxが600から601にかけて互換性が壊れたから、自作のライブラリの追従作業をしたが

3:02 AM

プロジェクトのSwiftSyntaxを601にアップデートしようとしたら

3:02 AM

今週新たに入れたばっかのライブラリの swift-memberwise-init-macro が SwiftSyntax601 に対応してなくてスタックした・・・

3:03 AM

ビルド全体で１つのSwiftSyntaxしか存在できないのが本当に難しい

3:07 AM

あぶねー pointfreeco/swift-snapshot-testing まで問題が波及したけど

3:07 AM

ここは <602 だ

3:10 AM

なんか真っ黄色になった

3:11 AM

こんなことできるのか〜

3:11 AM

同じ名前を２つのモジュールに置いてエイリアスして左側だけ警告

これもすごいな・・・

3:22 AM

新しいSwiftSyntaxの場合はextension経由で警告出して実装は実行時に潰すけど、古いSwiftSyntax(見えないけど)だったらこれがないから動作するのか (edited)

conformingTo protocols: [TypeSyntax], の方を使うとSwiftSyntaxの下限のどこが切れるのかがよくわかんないな

いや、これもとから真っ黄色なのか

3:37 AM

509と600でクロスコンパイルしたいからか・・・？

3:39 AM

コントリビュート激ムズだ

3:41 AM

こういう感じか？

わー、そうだ。510→600でめっちゃdeprecateされてるんだ

3:52 AM

509でビルドしたら綺麗になった。

3:53 AM

601 には SE-0452 Integer Generic Parameters が入ったのがヤバいんだな Swift 6.2 からだけど、601 に experimental で入ってる

なんかこれが出るようになってる

warning: 'swift-syntax': found 1 file(s) which are unhandled; explicitly declare them as resources or exclude from the target ***/.build/checkouts/swift-syntax/Sources/SwiftLexicalLookup/CMakeLists.txt

(edited)

main でも release/6.2 でも修正済みなのでチェックアウトされている swift-syntax のコミットが進めばそのうち消えると思います． https://github.com/swiftlang/swift-syntax/pull/3002

Fix build warnings by ahoppen · Pull Request #3002 · swiftlang/sw...

Mostly, ensure that we only use @_implementationOnly if we build with RESILIENT_LIBRARIES. Also, strerror is marked as unsafe and deprecated on Windows. It looks like this is because strerror is no...

1

そういえばいつのまにかBodyMacro使える状態になってたんですね

お、そうなんやなんか実用例あるんでしたっけ

いや6.0でimplementedって書いてあったのと野良のライブラリも使ってるなーってくらいです (edited)

野良でなんかおもしろい使い方ありました？ swift-distributed-tracingの@Spanはプロポーザルにはあったけど

あまり詳しくはみてなくてわかりません。モックライブラリが多い気はします

1:21 PM

関数の挙動を捻じ曲げるための隙間を作るのには良さそうですね

あーモックで関数読んだ回数とか差し替えフックとか入れるところには使えそうですね

Xcode26から、マクロの依存宣言が足りないかのような警告が出るけど、依存を書いても消えない。

これ報告しないといけないやつかも

5:42 AM

そのパッケージを直接ビルドしたときは大丈夫なのもよくわからない

https://forums.swift.org/t/preview-swift-syntax-prebuilts-for-macros/80202/95 Xcode26 でビルド済みSwiftSyntaxが壊れてるやつ報告と返答がある

[Preview] Swift-Syntax Prebuilts for Macros

Did anyone else start running into this today? This was working fine for weeks, and suddenly we get: cannot load module 'SwiftSyntax' built with SDK 'macosx15.2' when using SDK 'macosx15.5': /tmp/build/SourcePackages/prebuilts/swift-syntax/600.0.1/6.1-MacroSupport-macos_aarch64/Modules/SwiftSyntax.swiftmodule

12:48 AM

将来解決するらしい

プレビルトスレに悲鳴が増えてるw

10:28 AM

やはりバイナリは難しい

余裕で壊れてて明示的に機能オフにしました

11:54 AM

これlibISSPにやってること戻ってる気がする

libISSPたしかに！コンパイラ同梱でバージョンが固定されてたの同じやん

12:20 PM

In 6.2, we now use the compiler version from ‘swiftc -print-target-info’ to make sure we use the prebuilt swift modules appropriate for that compiler version.

一応能動的に環境を調べて、使える時だけバイナリを使うようにするつもりなんやな