Docs soundness check fails in the vicinity of platform-specific API

オープン
#166 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
swift

調査の方向性

Issueで説明されているLinux DocC bundleのビルドとsoundnessチェックから始め、Linuxで@available(unavailable)が付けられたシンボルへの参照に焦点を当てます。言及されているpackageとtargetの各バリエーションにわたって、チェックでプラットフォーム固有のAPIをどのように扱えるかを比較し、Issueに列挙されている可能なアプローチを検討します。プラットフォーム固有の有効なドキュメントに対してチェックが誤って失敗しなくなれば完了です。

索引モデルが issue の本文から書いたものです。

説明

The docs soundness check runs on Linux currently. Swift Testing has some Apple-specific API (and some Windows-specific API) and our DocC bundle contains some references to symbols that are marked @available(unavailable) on Linux. As a result, when we build our DocC bundle on Linux, those symbols are called out as missing. When we run the soundness check, it fails outright.

We need some general way to solve this problem for packages/targets/etc. that have platform-specific API variation. I'm not sure what a good solution looks like here. I don't know if that means making a change in swift-docc to introduce something like #if, or if it means having the soundness check run for multiple targets and combine results, or set a Swift compiler condition during the build that we can use to "opt out" some code from the check, or…

This problem isn't specific to Swift Testing: swift-system and swift-subprocess are also impacted, for example.

主要言語
Swift
スター
115
フォーク
57
平均マージ
1日 8時間
マージ済み PR(30日)
3

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

swiftlang/github-workflows のほかの issue

swiftlang/github-workflows の issue をすべて見る

似ている issue

Swift の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。