Docs soundness check fails in the vicinity of platform-specific API
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
- Tipo de issue
- Funcionalidade
- Clareza
- Precisa de esclarecimento
- Status de atividade
- Estagnada
- Stack de tecnologia
- swift
- Domínio
- ci-cd, documentation
Direção de pesquisa
Comece com o build do bundle Linux DocC e a verificação de soundness descritos na issue, concentrando-se nas referências a símbolos marcados com @available(unavailable) no Linux. Compare como a verificação poderia lidar com APIs específicas da plataforma entre as variações de package e target mencionadas e considere as possíveis abordagens listadas na issue. O trabalho estará concluído quando a verificação não falhar mais incorretamente para documentação válida específica da plataforma.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Swift
- Estrelas
- 115
- Forks
- 60
- Merge médio
- 2d 13h
- PRs com merge (30d)
- 4
Preparar o ambiente
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de swiftlang/github-workflows
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
swiftlang/github-workflows#261 ·
-
Update from actions/checkout@v4 to v6Talvez já em andamento Um pull request vinculado a esta issue está aberto ou já foi mesclado. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
swiftlang/github-workflows#258 · 1 comentário ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 68/100
swiftlang/github-workflows#312 ·
-
Android testing is broken with swiftbuildTalvez já em andamento Um pull request vinculado a esta issue está aberto ou já foi mesclado. Aberta
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 58/100
swiftlang/github-workflows#277 · 1 comentário ·
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 52/100
swiftlang/github-workflows#267 ·
Todas as issues de swiftlang/github-workflows
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
openwatersio/slackwater-ios#736 ·
Mantenedores costumam responder em até 1 dia
-
agent/sec-check help wanted security stage/010-actionable
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
hivecommons/hotshot#235 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 74/100
Emanuele-web04/remodex#203 ·
Mantenedores costumam responder em até 1 dia
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 92/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 75/100
521xueweihan/HelloGitHub#4016 ·