Recommendations for enabling more compiler checks

Open
#37 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Documentation
Clarity
Needs clarification
Activity status
Stale
Tech stack
cpp
Domain
compilers

Research direction

Start by reviewing the issue's four questions about aggressive warnings in clang++ 4.x, including -Wconversion and -Weverything. Research which flags are broadly useful, scenario-dependent, or compiler-specific, then document a clear recommendation and explain how small projects could apply it; done means the warning guidance answers all four questions.

Written by the indexing model from the issue text.

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

Dominant language
No language data
Stars
110
Forks
17
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mapbox/cpp

All issues in mapbox/cpp

Similar issues

More Compilers issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.