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

Aperta
#166 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
swift
Ambito
ci-cd, documentation

Direzione di ricerca

Inizia con la build del bundle Linux DocC e il controllo di soundness descritti nell’issue, concentrandoti sui riferimenti ai simboli contrassegnati con @available(unavailable) su Linux. Confronta come il controllo potrebbe gestire le API specifiche della piattaforma nelle variazioni di package e target menzionate, e considera i possibili approcci elencati nell’issue. Il lavoro è completato quando il controllo non fallisce più erroneamente per la documentazione valida specifica della piattaforma.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Swift
Stelle
115
Fork
57
Merge medio
1g 8h
PR unite (30g)
3

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di swiftlang/github-workflows

Tutte le issue di swiftlang/github-workflows

Issue simili

Altre issue su Swift

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.