Docs soundness check fails in the vicinity of platform-specific API
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- swift
- Área
- ci-cd, documentation
Línea de trabajo
Comienza con la compilación del bundle de Linux DocC y la comprobación de soundness descrita en el issue, centrándote en las referencias a símbolos marcados con @available(unavailable) en Linux. Compara cómo podría la comprobación gestionar la API específica de la plataforma entre las variaciones de package y target mencionadas, y considera los posibles enfoques enumerados en el issue. Se considera terminado cuando la comprobación ya no falla incorrectamente para documentación válida específica de la plataforma.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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.
- Lenguaje dominante
- Swift
- Estrellas
- 115
- Forks
- 57
- Merge medio
- 1 d 8 h
- PR fusionados (30 d)
- 3
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de swiftlang/github-workflows
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
swiftlang/github-workflows#305 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
swiftlang/github-workflows#261 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
swiftlang/github-workflows#258 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
swiftlang/github-workflows#312 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
swiftlang/github-workflows#277 · 1 comentario ·
Todos los issues de swiftlang/github-workflows
Issues similares
-
pending-maintainer-response pending-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
make notarise-dmg notarises whichever dist/ image sorts last, not the one make dmg just built Abiertoarea:build bug good first issue P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
uttrflow/uttrflow-swift#1412 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
enhancement
Dificultad 1/5 Menos de una hora Aptitud para principiantes 80/100
-
T-Defect
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
element-hq/element-x-ios#6191 ·