mapbox / mapbox/cpp

Recommendations for enabling more compiler checks

Abierto
#37 5 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
Sin datos de lenguaje
Estrellas
110
Forks
17
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

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++)?

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Empieza revisando las cuatro preguntas del issue sobre las advertencias agresivas en clang++ 4.x, incluidas -Wconversion y -Weverything. Investiga qué flags son ampliamente útiles, dependen del escenario o son específicos del compilador; después documenta una recomendación clara y explica cómo podrían aplicarla los proyectos pequeños; el trabajo estará terminado cuando las indicaciones sobre las advertencias respondan a las cuatro preguntas.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
cpp
Área
compilers
Tipo de issue
Documentación
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.