Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Recommendations for enabling more compiler checks

未關閉
#37 5 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
25/100
Issue 類型
文件
描述清晰度
需要釐清
活躍度
停滯
技術堆疊
cpp
領域
compilers

研究方向

首先,檢視 issue 中關於 clang++ 4.x 中積極警告的四個問題,包括 -Wconversion 和 -Weverything。研究哪些 flags 廣泛有用、取決於情境或特定於編譯器,然後記錄一項明確的建議,並說明小型專案可以如何套用;當警告指南回答了全部四個問題時,即視為完成。

由索引模型根據 Issue 內容生成。

描述

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

主要語言
沒有語言資料
星號
110
分支
17
PR 合併指標
30 天內沒有已合併 PR

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

mapbox/cpp 的其他 Issue

查看 mapbox/cpp 的全部 Issue

相似的 Issue

更多 Compilers Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。