Recommendations for enabling more compiler checks
Personne n'a encore pris cette issue.
- Langage dominant
- Aucune donnée de langage
- Étoiles
- 110
- Forks
- 17
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
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++)?
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par examiner les quatre questions de l’issue concernant les avertissements agressifs dans clang++ 4.x, notamment -Wconversion et -Weverything. Recherchez quels flags sont largement utiles, dépendent du scénario ou sont spécifiques au compilateur, puis documentez une recommandation claire et expliquez comment les petits projets pourraient les appliquer ; le travail sera terminé lorsque les recommandations concernant les avertissements répondront aux quatre questions.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- cpp
- Domaine
- compilers
- Type d'issue
- Documentation
- Difficulté
- 5/5
- Temps estimé
- Plus d'une semaine
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 25/100