Recommendations for enabling more compiler checks

Offen

#37 erstellt am 12.10.2017 5 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit: 5/5
Geschätzter Aufwand: Über eine Woche
Anfängerfreundlichkeit: 25/100

Issue-Typ: Dokumentation
Klarheit: Muss geklärt werden
Aktivitätsstatus: Veraltet
Tech-Stack: cpp
Bereich: compilers

Rechercherichtung

Beginnen Sie mit der Prüfung der vier Fragen des Issues zu aggressiven Warnungen in clang++ 4.x, einschließlich -Wconversion und -Weverything. Untersuchen Sie, welche Flags allgemein nützlich, szenarioabhängig oder compilatorspezifisch sind, dokumentieren Sie anschließend eine klare Empfehlung und erläutern Sie, wie kleine Projekte sie anwenden könnten; abgeschlossen ist die Aufgabe, wenn die Hinweise zu Warnungen alle vier Fragen beantworten.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache: Keine Sprachdaten
Sterne: 110
Forks: 17
PR-Merge-Kennzahlen: Keine gemergten PRs in 30 T.

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
Forken Sie das Repository und arbeiten Sie in einem Branch.
Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus mapbox/cpp

[glossary] add details about why forward declarations are useful Offen

glossary

Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 68/100

mapbox/cpp#53 · Erstellt am 30.3.2018
Changes needed as mapbox-gl-native is public archive Offen

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 25/100

mapbox/cpp#59 · Erstellt am 24.8.2023
Docs on ABIs Offen

Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 30/100

mapbox/cpp#55 · 2 Kommentare · Erstellt am 30.4.2018
clang-tidy v. -Weffc++ Offen

Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100

mapbox/cpp#54 · 1 Kommentar · Erstellt am 24.4.2018
docs/learning-resources.md blank Offen

Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 35/100

mapbox/cpp#52 · 5 Kommentare · Erstellt am 13.3.2018

Alle Issues in mapbox/cpp