Recommendations for enabling more compiler checks
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
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.
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:
-
🍇 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++)?
- Lenguaje dominante
- Sin datos de lenguaje
- Estrellas
- 110
- Forks
- 17
- Métricas de merge de PR
- Sin PR fusionados en 30 d
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 mapbox/cpp
-
glossary
Dificultad 1/5 Menos de una hora Aptitud para principiantes 68/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 25/100
-
Docs on ABIs Abierto
Dificultad 4/5 3-5 días Aptitud para principiantes 30/100
-
clang-tidy v. -Weffc++ Abierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
-
docs/learning-resources.md blank Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
Todos los issues de mapbox/cpp
Issues similares
-
todo:perf
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
-
StUnhex.number() misformats Long.MIN_VALUE as scientific notation instead of a plain integer Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
objectionary/eo#8894 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
objectionary/phie#154 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
objectionary/jeo-maven-plugin#1774 ·
-
Minor breakage w/ LLVM 7: `test_llvm.cpp: error: cannot convert 'llvm::Module' to 'llvm::Module*'` Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100