Docs soundness check fails in the vicinity of platform-specific API
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Accessibilité débutants
- 25/100
- Type d'issue
- Fonctionnalité
- Clarté
- À clarifier
- Activité
- À l'abandon
- Stack technique
- swift
- Domaine
- ci-cd, documentation
Piste de recherche
Commencez par le build du bundle Linux DocC et le contrôle de soundness décrits dans l’issue, en vous concentrant sur les références aux symboles marqués @available(unavailable) sur Linux. Comparez comment le contrôle pourrait gérer les API spécifiques à la plateforme selon les variations de package et de target mentionnées, et examinez les approches possibles listées dans l’issue. Le travail est terminé lorsque le contrôle n’échoue plus à tort pour une documentation valide spécifique à la plateforme.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
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.
- Langage dominant
- Swift
- Étoiles
- 115
- Forks
- 57
- Merge moyen
- 2 j 11 h
- PR mergées (30 j)
- 2
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de swiftlang/github-workflows
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
swiftlang/github-workflows#305 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
swiftlang/github-workflows#261 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
swiftlang/github-workflows#258 · 1 commentaire ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 68/100
swiftlang/github-workflows#312 ·
-
Difficulté 3/5 1-2 jours Accessibilité débutants 58/100
swiftlang/github-workflows#277 · 1 commentaire ·
Toutes les issues de swiftlang/github-workflows
Issues similaires
-
clawsweeper:linked-pr-open clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:ux-friction issue-rating: 🦞 diamond lobster P2
Difficulté 2/5 1-3 heures Accessibilité débutants 86/100
steipete/RepoBar#140 · 1 commentaire · 1 réaction ·
Les mainteneurs répondent en général sous 1 jour
-
area:dictation bug P2
Difficulté 2/5 1-3 heures Accessibilité débutants 88/100
uttrflow/uttrflow-swift#2551 ·
Les mainteneurs répondent en général sous 1 jour
-
bot:candidate
Difficulté 1/5 Moins d'une heure Accessibilité débutants 95/100
imbhargav5/open-recorder#1275 ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 84/100
EtanHey/brainlayer#984 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 68/100
Les mainteneurs répondent en général sous 1 jour