mapbox / mapbox/cpp

Recommendations for enabling more compiler checks

Ouverte
#37 5 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

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

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. 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

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.