CLANG-CHECK(1)

💅 CLANG-CHECK(1) 💅

ok so bestie, this is the manual page for clang-check — it lives in the User Commands section of the manual, and it's giving "compiler tooling but make it ✨fancy✨". buckle up, we're going in 🎀

---

🌸 NAME 🌸

clang-check — manual page for clang-check 15 🦋

---

✨ DESCRIPTION ✨

ok so here's the whole vibe, the entire usage of this thing, no cap:

USAGE: clang-check [options] <source0> [... <sourceN>]

and now… OPTIONS 👑 (yes we're doing options, yes there are a lot, yes we're doing all of them)

💖 Generic Options 💖

these are the basics, the everyday essentials, the main character options fr:

• --help — shows you the available options. and if you want even more, there's --help-hidden for that 💀
• --help-list — shows you the list of available options. and yep, there's --help-list-hidden for even more of them too 🫶
• --version — tells you the version of this program, iconic behaviour honestly ⭐

🦋 clang-check options 🦋

the real ones, the ones you actually came here for:

• --analyze — run the static analysis engine 🔍
• --analyzer-output-path=<string> — write output to <file> 📝
• --ast-dump — build ASTs and then debug dump them 🌳
• --ast-dump-filter=<string> — use with -ast-dump or -ast-print to dump/print only AST declaration nodes having a certain substring in a qualified name. use -ast-list to list all filterable declaration node names 👀
• --ast-list — build ASTs and print the list of declaration node qualified names 📋
• --ast-print — build ASTs and then pretty-print them 💅 (pretty-print!! she's literally named after us)
• --extra-arg=<string> — additional argument to append to the compiler command line ➕
• --extra-arg-before=<string> — additional argument to prepend to the compiler command line 🔼
• --fix-what-you-can — apply fix-it advice even in the presence of unfixable errors. like, do what you can bestie, it's fine 😭
• --fixit — apply fix-it advice to the input source 🔧
• -p <string> — build path 🗂️
• --syntax-tree-dump — dump the syntax tree 🌲
• --tokens-dump — dump the preprocessed tokens 🎟️

---

🧚 the -p lore (build path) 🧚

so, -p <build-path> is used to read a compile command database. periodt.

for example, it can be a CMake build directory in which a file named compile_commands.json exists (use the -DCMAKE_EXPORT_COMPILE_COMMANDS=ON CMake option to get this output, iykyk). when no build path is specified, a search for compile_commands.json will be attempted through all parent paths of the first input file.

see: https://clang.llvm.org/docs/HowToSetupToolingForLLVM.html for an example of setting up Clang Tooling on a source tree 🌈

---

🌸 the <source0> ... source files situation 🌸

<source0> ... specify the paths of source files. these paths are looked up in the compile command database. no cap, here are the rules:

• if the path of a file is absolute, it needs to point into CMake's source tree.
• if the path is relative, the current working directory needs to be in the CMake source tree and the file must be in a subdirectory of the current working directory.
• "./" prefixes in the relative files will be automatically removed, but the rest of a relative path must be a suffix of a path in the compile command database.

---

💜 examples, because we love a demonstration 💜

for example, to run clang-check on all files in a subtree of the source tree, use:

find path/in/subtree -name '*.cpp'|xargs clang-check

or using a specific build path:

find path/in/subtree -name '*.cpp'|xargs clang-check -p build/path

note, that path/in/subtree and current directory should follow the rules described above 👆 (yes, the rules we just went over, don't skip them bestie)

---

and that's the whole page!! 🎀 this was clang-check 15, dated July 2023 💖 thanks for reading, you ate that fr fr 🫶✨💅