Swift 5.2では関数・メソッドの最後の引数がデフォルト引数の場合、その1つ前のクロージャの引数をtrailing closureとして呼べるようになった

タイトルがほぼ全てです。

func foo(_ closure: () -> Void, defaultArg: Int = 0) {
  closure()
}

foo { print("foo") }

このコードはSwift 5.2では動作しますが、Swift 5.1以前ではコンパイルエラーになります。

Nimbleに挙がったissueでそのことに気付きました。

Discordのswift-developers-japanで話してみたところ、apple/swiftのこのコミットが該当の変更であることを分かりました。

さらに芋づるで分かったことがあって、一時期のSwiftのDevelopment SnapshotでNimbleのビルドが通らなくなったり、そのリグレッションがきっかけでapple/swift-source-compat-suiteにNimbleが追加されたのもこの辺りに関連した変更の影響でした。

• [SR-12291] Regression in overload resolution - Swift
• Doesn't build with the latest Swift Development Snapshot (DEVELOPMENT-SNAPSHOT-2020-02-21-a) · Issue #733 · Quick/Nimble

色々繋がっていて面白いですね、めでたしめでたし。

GitHub ActionsでのJestのテスト実行時に失敗箇所をPRへのアノテーションとして表示するレポーター

このような便利なパッケージがありました。

GitHub Actionsにはworkflow commandsと呼ばれる、echoコマンドと特定の形式の文字列を使うことでActionsの処理に一部介入できる機能があります。その中にはファイルの特定の箇所（行・カラム）にdebug/warning/errorメッセージをPRのアノテーションとして追加できるコマンドがあります。jest-github-actions-reporterではJestのレポーターの実装としてそのSetting an error messageコマンドを使い、Jestのテストの失敗結果をerrorアノテーションとしてPRの差分表示上で簡単に結果が閲覧できるようになっています。

こういうやり方があるのはRenovateのこのPRで気付きました。

きっとそのためのJestのレポーターをパッケージとして作成・公開している人がいるだろうと探してみたら、案の定存在した次第です。

GitHub Actionsで日々の暮らしを楽にしていきましょう。

AndroidのFirebase Installations version 16.2.0で追加されたlintチェックがAndroid Gradle plugin 3.6と互換性がなくてビルドできない

Firebase OSSのこちらのIssueで報告されているように、Android Gradle plugin 3.6（Android Studio 3.6）以上のプロジェクトでFirebase Installations version 16.2.0が依存性に入るとlintでビルドが失敗するようになります。

追加されたlintというのはこちら:

https://firebase.google.com/support/release-notes/android?hl=ja#installations_v16-2-0

Added a lint check to the compile process that prevents parallel usage of Firebase installations and incompatible versions of the Firebase Instance ID SDK that are older than firebase-iid:20.1.0. Firebase installations creates FIDs as Firebase client identifiers. Versions of the Firebase Instance ID SDK before v20.1.0 created different Firebase client identifiers: Instance IDs. This check prevents problems for Firebase targeting that might be caused by conflicting Firebase client identifiers.

数時間前にはこの問題を修正するPRがマージされたので、近々修正されたバージョンがリリースされるはずです。しばらく待ちましょう。

待てずにすぐFirebaseの各種バージョンを上げたい場合は、Issueにあるように該当のlintを無効にすることでひとまず回避することができます。

android {
    lintOptions {
        disable "IncompatibleIidVersion"
    }
}

Swift 5.2

iOS 13.4とXcode 11.4と共にSwift 5.2がリリースされましたね。

Swift.org - Swift 5.2 Released!

• SE-0249 Key Path Expressions as Functions
  • 関数・クロージャが要求される箇所でKeyPathリテラルを書くとKeyPath型ではなく関数・クロージャを返してくれるようになった
• SE-0253 Callable values of user-defined nominal types
  • SE-0216の@dynamicCallableに対してstatic callableとも呼ばれた機能。callAsFunctionというメソッドを定義することで、型や値を直接関数のように実行することができる。
• Improved Compiler Diagnostics
  • コンパイルエラーのメッセージの改善
• Code Completion Improvements
  • コード補完の改善
• Improved Build Algorithms
  • 主にインクリメンタルビルドの速度の改善
• Debugger Improvements
• Swift Package Manager
  • 依存パッケージがSwift 5.2のパッケージ定義を使っている場合、その依存パッケージのテストターゲットでしか使われていない孫依存パッケージは利用元のプロジェクトでは解決されなくなる（不要なtransitive dependencies：推移的依存性がなくなる）
• SwiftSyntax Updates
  • ノード階層がprotocolベースからstructベースになったことによる速度改善
• Language Server Protocol Updates
  • sourcekit-lspというLSPのランゲージサーバーがXcodeとCommand Line Toolsに同梱されるようになった
    • Visual Studio CodeなどでSwiftを書くのが捗るようになりそう
  • FixItsとLocal Refactoringのサポート追加

というラインナップになっています。今日から早速どんどん活用していきましょう！ ⚡️

OkHttp 4.xと3.xでのバイナリ非互換の事例

Kotlinで書き直されたOkHttp 4.xはJavaで書かれた3.xと基本的にソース互換性・バイナリ互換性が保たれているが、バイナリ非互換でクラッシュするケースに遭遇した。https://t.co/ZE0VV1Gkwm

— Sho Ikeda (@ikesyo) 2020年2月17日

具体的には、「OkHttp 3.xのJavaNetCookieJarを使っているライブラリ」を使うアプリでOkHttp 4.xを使おうとすると、Util.delimiterOffsetというstaticメソッドがString.delimiterOffsetという拡張関数に変わっており、前者のメソッドが存在しなくて死んでしまう。

— Sho Ikeda (@ikesyo) 2020年2月17日

• 4.xの String.delimiterOffset: https://github.com/square/okhttp/blob/4bb66bcf5e1b11bd13f088cc78188c2bdc075c6f/okhttp/src/main/java/okhttp3/internal/Util.kt#L207-L227
• 3.xの Util.delimiterOffset: https://github.com/square/okhttp/blob/parent-3.14.6/okhttp/src/main/java/okhttp3/internal/Util.java#L363-L383

GitHub Actionsのcheckoutアクションがv2でいろいろ変わって便利になっていた

GitHub Actionsをそこそこ使っている今日この頃です。さて、Actionsといえば普遍的に使う、リポジトリをチェックアウトする actions/checkout がありますが、このアクションがv2になり、色々と挙動が変更・改善されてい便利そうなのでいくつかご紹介。

• https://github.com/actions/checkout/releases/tag/v2.0.0
• https://github.com/actions/checkout#whats-new

---

• fetchのdepthがデフォルトで1になり、フェッチが速くなった
• チェックアウトの際に使用されたActions発行のトークンがgitのconfigに永続化され、リモートへのpushなどの操作が設定要らずでできるようになった
• ブランチのチェックアウト時にはローカルブランチを作るようになった（detached HEADにならない）
• チェックアウト先のパスを指定する path設定が絶対パスではなく $GITHUB_WORKSPACE 基準の相対パスになった

特に1〜3つ目は細かい困りごと・面倒ポイントを潰してくれていて好印象です。アクションの新バージョンには気づきにくいですが、どんどんアップデートして便利に使っていきたいですね。

追記

submoduleのチェックアウトが逆にv2では現在サポートされていないということなので、手でやる必要があり要注意です。この手段もSSHでは動かないとかもあり、submoduleを使っている方はしばらくv1の方がいいかもしれません。

https://github.com/actions/checkout#checkout-submodules

- uses: actions/checkout@v2
- name: Checkout submodules
  shell: bash
  run: |
    auth_header="$(git config --local --get http.https://github.com/.extraheader)"
    git submodule sync --recursive
    git -c "http.extraheader=$auth_header" -c protocol.version=2 submodule update --init --force --recursive --depth=1

• Checkout with submodules? · Issue #81 · actions/checkout
• submodule support removed in v2 · Issue #133 · actions/checkout

和暦と改元とうるう年が組み合わさったバグの思い出

あけましておめでとうございます。新年一発目の投稿は2019年の思い出です。

そういえば去年面白かったバグで、とある有効期限チェックで、2019年8月から半年後の月末が2020年2月末、つまり閏年なので2月29日になるのだけど、よくある和暦バグと組み合わさって令和2020年2月29日と解釈しようとして、令和2020年は閏年ではないのでパースに失敗する、ということがありました。

— Sho Ikeda (@ikesyo) 2020年1月1日

これ、改元があったことも絶妙に影響していて、仮に平成のままだったとしたら平成2020年（西暦4008年）は閏年なので問題なかったのである。

— Sho Ikeda (@ikesyo) 2020年1月1日

ということで本年もよろしくお願いします 🙏