mapbox / mapbox/cpp

Recommendations for enabling more compiler checks

Aberta
#37 5 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Linguagem predominante
Sem dados de linguagem
Estrelas
110
Forks
17
Métricas de merge de PRs
Nenhum PR com merge em 30d

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:

1) 🍇 Which flags we should always enable for all code no matter what?

2) 🍊 What additional flags may be very useful in some scenarios/some code bases?

3) 🍏 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?

4) 🍎 What compiler specific flags should we recommend (that only currently work for clang++ or g++)?

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

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.

Avaliação

Stack de tecnologia
cpp
Domínio
compilers
Tipo de issue
Documentação
Dificuldade
5/5
Tempo estimado
Mais de uma semana
Status de atividade
Estagnada
Clareza
Precisa de esclarecimento
Facilidade para iniciantes
25/100

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.