Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
#166 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
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 小时
30 天内合并 PR
3

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

swiftlang/github-workflows 的其他 Issue

查看 swiftlang/github-workflows 的全部 Issue

相似的 Issue

更多 Swift Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。