Docs soundness check fails in the vicinity of platform-specific API
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 25/100
- Issue-Typ
- Feature
- Klarheit
- Muss geklärt werden
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- swift
- Bereich
- ci-cd, documentation
Rechercherichtung
Beginne mit dem Linux-DocC-Bundle-Build und dem im Issue beschriebenen Soundness-Check, mit Fokus auf Verweise auf Symbole, die unter Linux mit @available(unavailable) gekennzeichnet sind. Vergleiche, wie der Check plattformspezifische API über die im genannten Package und den genannten Target-Varianten hinweg behandeln könnte, und berücksichtige die im Issue aufgeführten möglichen Ansätze. Als erledigt gilt die Aufgabe, wenn der Check für gültige plattformspezifische Dokumentation nicht mehr fälschlicherweise fehlschlägt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Swift
- Sterne
- 115
- Forks
- 57
- Ø Merge
- 2 T. 13 Std.
- Gemergte PRs (30 T.)
- 4
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus swiftlang/github-workflows
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
swiftlang/github-workflows#261 ·
-
Update from actions/checkout@v4 to v6Evtl. vergeben Ein verknüpfter Pull Request ist offen oder bereits gemergt. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
swiftlang/github-workflows#258 · 1 Kommentar ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
swiftlang/github-workflows#312 ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 58/100
swiftlang/github-workflows#277 · 1 Kommentar ·
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 52/100
swiftlang/github-workflows#267 ·
Alle Issues in swiftlang/github-workflows
Ähnliche Issues
-
area:ui enhancement good first issue
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
s3onghyun/bulchimbeon#22 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Maintainer antworten meist innerhalb von 1 Tag
-
[BUG] File transcription skips audio chunks shorter than one secondEvtl. vergeben @sabbah13 hat das heute übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
altic-dev/FluidVoice#1161 ·
Maintainer antworten meist innerhalb von 1 Tag
-
swift.md: `Date(myString, strategy: .iso8601)` example omits `try` — the initializer is throwingOffen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100