Recommendations for enabling more compiler checks
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
Direção de pesquisa
Comece revisando as quatro perguntas da issue sobre avisos agressivos no clang++ 4.x, incluindo -Wconversion e -Weverything. Pesquise quais flags são amplamente úteis, dependem do cenário ou são específicas do compilador; em seguida, documente uma recomendação clara e explique como projetos pequenos poderiam aplicá-las; o trabalho estará concluído quando as orientações sobre avisos responderem às quatro perguntas.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Compilers enable by default, a set of warnings they will emit on dodgy or less-than-ideal code. These defaults:
- a. change over time
- b. vary between compiler versions
- c. do not include some of the most valuable warnings that might help prevent bugs
This issue is designed to focus on the problem of c from the perspective of the latest clang++ 4.x versions.
Enabling more warnings than compilers do by default can be an important way of catching bugs early. For example integer truncation bugs can often be detected by enabling -Wconversion, which is not on by default.
Enabling more warnings is very difficult to do after a project is big (e.g. https://github.com/Project-OSRM/osrm-backend/pull/4495 and https://github.com/mapnik/mapnik/issues/2907 and https://github.com/mapnik/mapnik/issues/3204). It is best not to wait and rather to start a project with aggressive warnings from the beginning.
So, the question then becomes: what is a good set of aggressive warnings to enable at the start of a project (or to try to integrate into existing projects)?
In particular:
-
🍇 Which flags we should always enable for all code no matter what?
-
🍊 What additional flags may be very useful in some scenarios/some code bases?
-
🍏 For small projects where it is feasible, can we actually start with
clang++s-Weverything? This, when feasible, might be ideal. How to do it? -
🍎 What compiler specific flags should we recommend (that only currently work for clang++ or g++)?
- Linguagem predominante
- Sem dados de linguagem
- Estrelas
- 110
- Forks
- 17
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
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 mapbox/cpp
-
glossary
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 68/100
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 25/100
-
Docs on ABIsAberta
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 30/100
-
clang-tidy v. -Weffc++Aberta
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 30/100
-
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 35/100
Issues semelhantes
-
backend:DirectX
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
llvm/llvm-project#227530 ·
Mantenedores costumam responder em até 1 dia
-
`enzymexla.linalg.lu` lowering fails for a tall matrix: the permutation is built with the pivot typeAberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
EnzymeAD/Enzyme-JAX#3286 ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 82/100
objectionary/phino#1600 ·
Mantenedores costumam responder em até 1 dia
-
compiler enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 86/100
tenstorrent/tt-lang#1141 ·
Mantenedores costumam responder em até 5 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia