| # Lint |
| |
| We use clang-tidy to lint C++ code and aim to keep the repository warning-clean. |
| The linter is configured in the root level `.clang-tidy` file. Developers |
| should not create additional configuration files at a lower level, as |
| this will cause disagreements in the tree. |
| |
| ## How to lint |
| |
| `fx lint` is a Fuchsia script that wraps language-specific linters in a common |
| command line interface. It gathers a list of files, based on the options you |
| specify, separates them by matching linter, and executes each required linter. |
| `clang-tidy` is used for C and C++ files. |
| |
| Without any other arguments, `fx lint` lints the files in your |
| most recent git commit, and passes them through the linter: |
| |
| ``` |
| fx lint |
| ``` |
| |
| To restrict linting to C++, add a double-dash (--) followed by the |
| file pattern(s) to match, such as: |
| |
| ``` |
| fx lint -- '*.cc' '*.cpp' |
| ``` |
| |
| To run a specific GN target through the linter, use: |
| |
| ``` |
| fx lint --target=<target> |
| ``` |
| |
| In order to lint all files under the current working directory, add `--all`. |
| Running `fx lint --all` from the top-level `fuchsia` directory is generally not |
| recommended, and will likely take several hours to complete. Be certain you |
| `cd` to the best top level directory for your analysis requirements. For example: |
| |
| ``` |
| (cd <your/subdir>; fx lint --all -- '*.cc') |
| ``` |
| |
| You can also add `--fix` in order to automatically generate fixes for some (but |
| not all) of the warnings. |
| |
| Additional options and examples are documented in the tool itself. For the most up |
| to date documentation on `fx lint`, including examples, run: |
| |
| ``` |
| fx lint --help |
| ``` |
| |
| ## Suppressing warnings |
| |
| Any warning can be suppressed by adding a `// NOLINT(<check_name>)` or a |
| `// NOLINTNEXTLINE(<check_name>)` comment to the offending line. It is also |
| possible to disable the check entirely within the repository by editing the |
| root level `.clang-tidy` file. |
| |
| ## Checks |
| |
| There are a number of check categories enabled, and specific checks within them |
| have been disabled for the reasons below. The list of enabled check categories |
| is as follows: |
| |
| - `bugprone-*` |
| - `clang-diagnostic-*` |
| - `google-*` |
| - `misc-*` |
| - `modernize-` |
| - `performance-*` |
| - `readability-*` |
| |
| This list tracks the reasons for which we disabled in particular [checks]: |
| |
| - `clang-diagnostic-unused-command-line-argument` - ninja-generated compilation |
| database contains the linker argument which ends up unused and triggers this |
| warning for every file |
| - `misc-noexcept*` - Fuchsia doesn't use C++ exceptions |
| - `misc-non-private-member-variables-in-classes` - We don't allow classes/structs |
| with a mix of private and public members, but all public is fine. |
| - `modernize-deprecated-headers` - Fuchsia uses old-style C headers |
| - `modernize-use-nodiscard` - Not generally used in the Fuchsia codebase |
| - `modernize-raw-string-literal` - the check was suggesting to convert `\xFF` |
| literals, which we'd rather keep in the escaped form. |
| - `modernize-return-braced-init-list` - concerns about readability of returning |
| braced initialization list for constructor arguments, prefer to use a |
| constructor explicitly |
| - `modernize-use-emplace` - enabled the IgnoreImplicitConstructors option to |
| comply with [Abseil Tip of the Week #112](https://abseil.io/tips/112). |
| - `modernize-use-equals-delete` - flagging all gtest TEST_F |
| - `modernize-use-trailing-return-type` - Fuchsia C++ code typically uses the |
| `int foo()` style of defining functions, and not the `auto foo() -> int` |
| style as recommended by this check. |
| - `readability-implicit-bool-conversion` - Fuchsia C++ code commonly uses implicit |
| bool cast of pointers and numbers |
| - `readability-isolate-declaration` - Zircon code commonly uses paired declarations. |
| - `readability-uppercase-literal-suffix` - Fuchsia C++ code chooses not to impose |
| a style on this. |
| |
| # Static analysis |
| |
| Strictly speaking it is not linting, but the Clang static analyzer can do |
| deep analysis to find bugs. See [Static analysis][static_analysis] for details. |
| |
| [static_analysis]: /docs/development/build/static_analysis.md |
| [checks]: https://clang.llvm.org/extra/clang-tidy/checks/list.html |