cpp-style
Skill1.1k starsChanged 35 days agoApache-2.0View on GitHub
C++ naming, formatting, static analysis, and RTTI rules for LuisaCompute.
1 other project uses a version of this.
Trending
Quiet since July.thin dataabout the whole repository
Most recently taken up by
- clice-io/clicetheir own version, first seen Oct 8, 2026
Who's talking about LuisaGroup/LuisaCompute
- Stack Overflow“c++ error: ‘struct std::atomic_flag’ has no member named ‘test’”Stack Overflow · Dec 26, 2022 · 1 votes
- Tencent/ncnn“optimize multi-head attention (increased shared-memory tile size, add fused kernel)”GitHub · Jul 10, 2026
- bazelbuild/bazel-central-registry“wanted: [LuisaGroup/LuisaCompute]”GitHub · Nov 8, 2025
- MuGdxy/SymEigen“Try to add support for luisa-compute”GitHub · Sep 15, 2025
- LuisaGroup/LuisaRender“Remove `util/u64.h` and use `Var<ulong>` instead”GitHub · Jun 2, 2024
The biggest 5 of 5 mentions linking to the repository that our crawl found. Each line is their own headline.
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- clice-io/clice★ 1.4ksame name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository22 other files it gives its agents.
- .github/copilot-instructions.mdCopilot instructions
- astSkill
- backend-architectureSkill
- cmakeSkill
- debugSkill
- gitSkill
- glslangSkill
- hlslSkill
- ir-pipelineSkill
- lc_apiSkill
- lc_native_shaderSkill
- lc_optimizeSkill
- llvm-spirvSkill
- lspSkill
- project_structureSkill
- renderdocSkill
- spirv_codegenSkill
- spv-optSkill
- testSkill
- xir-passesSkill
- xmakeSkill
- yyjsonSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 7 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Use the project C++ syntax checker:
- Distinctive: line 40
Constructor init: not forced one-per-line; no break before comma.
- Very specific: line 42
Spaces: before =, ctor-initializer :, inheritance :, range-for :.
- Distinctive: line 43
Alignment: after open brackets & operands.
- Distinctive: line 44
Includes/using: never auto-sort.
- Very specific: line 54
Run the project-root .clang-tidy (this skill ships no copy of it).
- Very specific: line 78
Prefer virtual dispatch or explicit type tags: Resource::Tag (include/luisa/runtime/rhi/resource.h:227), the luisa::compute::Type registry …
- Very specific: line 98
Use LUISA_ASSERT for fatal preconditions and LUISA_ERROR for unconditional failures, with an explicit <luisa/core/logging.h> include.
- Very specific: line 109
Test expected fatal failures in a separate process.
- Very specific: line 113
Run python scripts/check_cpp_no_throw.py (no arguments.
- Distinctive: line 122
Prefer fixed-width integer types:
- Very specific: line 124
Use: int32_t, uint32_t, int64_t, uint64_t, int16_t, uint16_t, int8_t, uint8_t
- Very specific: line 126
Prefer std::byte for raw byte data.
- Distinctive: line 132
After editing C++ files:
- Distinctive: line 145
When changing build-affecting files, configure and build a relevant target:
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Naming
- Classes / structs / enums:
CamelCase(Device,ResourceCreationInfo,Resource::Tag) - Functions & public vars:
snake_case(get_value,copy_from) - Private/protected members & functions:
_snake_case(_size,_move_from()) - Constants:
kCamelCase(kTensorShaderModel); macros areUPPER_SNAKE_CASE(LUISA_STRUCT) - Template params:
CamelCase(T,U,Key) - Namespaces:
luisa,luisa::compute,vstd, etc. Keep compact. - Exception: the CUDA
lcubdevice wrappers (include/luisa/backends/ext/cuda/lcub/) intentionally keep CUB'sPascalCaseentry points (SortPairs,DeviceReduce).
Syntax Check
Use the project C++ syntax checker:
python scripts/check_cpp_syntax.py <file>.cppFlags: --project-root DIR (default .), --clangd PATH (default clangd; falls back to clangd.path in .vscode/settings.json when present), --compile-commands-dir DIR (overrides auto-detection), --clang-tidy (off by default), --diagnostic-timeout SEC (default 30), -v/--verbose.
It drives clangd over LSP with --compile-commands-dir=<dir>, the database being auto-detected in the order .vscode, build, project root, then any build* directory, and only accepted if it actually contains the requested file — otherwise (e.g. a brand-new header) clangd falls back to the project root with no per-TU flags rather than skipping the file. -Werror/-Werror=//WX are demoted before the check. clangd still reads the root .clangd (CompileFlags.Add/Remove) for the project's warning suppressions. Exit status: 0 clean, 1 errors, 2 tool failure. scripts/check_all_cpp_syntax.py runs the same check over every file of a database (default --compile-commands .vscode/compile_commands.json).
Formatting
Format with the project-root .clang-format (this skill ships no copy of it). CI does not run clang-format.
Base: LLVM style. Key overrides:
- Indent: 4 spaces, no tabs (
IndentWidth: 4,UseTab: Never,TabWidth: 4). Continuation indent 4. Case labels indented. Preprocessor body indent 2 (PPIndentWidth: 2) but directives stay at column 0 (IndentPPDirectives: None). - Braces: K&R (attach). No break before braces. Indent braces off.
- Line width: unlimited (
ColumnLimit: 0). - Pointers/refs: right-aligned (
int *p,int &r;PointerAlignment: Right,ReferenceAlignment: Right). - Access modifiers: indent offset
-4(flush withclass). Empty lines before/after left as-is. - Short constructs: allow single-line for short blocks, functions, ifs, loops, lambdas, enums, case labels.
- Constructor init: not forced one-per-line; no break before comma.
- Templates / concepts: break declarations only when multiline; indent requires clause.
- Spaces: before
=, ctor-initializer:, inheritance:, range-for:. No space after C-style casts,!,templatekeyword, before braced lists. No space in empty parens or before trailing comments. - Alignment: after open brackets & operands; don't align consecutive assignments.
- Includes/using: never auto-sort.
- Namespaces: compact when short (
CompactNamespaces: true,ShortNamespaceLines: 0= no line limit); no indentation inside (NamespaceIndentation: None). - Strings/comments: break string literals; don't reflow comments.
- Macros (
SpaceBeforeParens: Custom): theIfMacroslist gets a space before((AfterIfMacros: true), theForEachMacroslist does not (AfterForeachMacros: false); function-like macros never get one. Lists:ForEachMacros:LUISA_STRUCT,LUISA_BINDING_GROUP,LUISA_BINDING_GROUP_TEMPLATEIfMacros:$if,$elif,$else,$for,$while,$loop,$switch,$case,$defaultStatementMacros:LUISA_MAP
Static Analysis
Run the project-root .clang-tidy (this skill ships no copy of it). It is a single Checks: string: everything off with -*, then 142 individually named checks — there are no category globs and no WarningsAsErrors/HeaderFilterRegex/per-check options. Prefix coverage:
- bugprone- (50 checks)
- cert- (9)
- cppcoreguidelines- (4:
interfaces-global-init,narrowing-conversions,pro-type-member-init,slicing) - google- (3:
default-arguments,explicit-constructor,runtime-operator) - hicpp- (2:
exception-baseclass,multiway-paths-covered) - misc- (6)
- modernize- (27)
- mpi- (2), openmp- (1)
- performance- (14)
- portability- (1:
simd-intrinsics) - readability- (23)
See the project-root .clang-tidy for the exact check list — enabling a whole category (e.g. readability-*) is not what the project config does.
No RTTI
RTTI is off for project code by default: lc_rtti (xmake.lua:71, default false) drives /GR- for cl/clang_cl and -fno-rtti (-fno-rtti-data for clang, -fno-rtti for gcc) in scripts/xmake_func.lua:435-455. RTTI is force-enabled when lc_rtti is on or the Python bindings are built (_lc_enable_py, scripts/xmake_func.lua:438) because pybind11 needs it; the CMake build adds no global RTTI flag, only -fno-rtti//GR- on LLVM-linked targets when the LLVM package has RTTI off (src/backends/common/CMakeLists.txt:197-200). Do not use:
dynamic_cast— usestatic_castwhen the type is known (e.g.static_cast<CUDADeviceConfigExt *>(_device_config_ext.get()),src/backends/cuda/cuda_device.cpp:390)typeidstd::type_info
Prefer virtual dispatch or explicit type tags: Resource::Tag (include/luisa/runtime/rhi/resource.h:227), the luisa::compute::Type registry (Type::of<T>(), include/luisa/ast/type.h:416, backed by detail::TypeDesc<T> in include/luisa/ast/type_registry.h), and luisa::to_string/magic_enum (include/luisa/core/magic_enum.h) for enum names. Vendored third-party code under src/ext is exempt; project glue inside src/ext is not.
No C++ Exception Raising in Project Code
The entire repository's own C++ code must not use throw, rethrow, or an
exception-raising helper/macro as a substitute. This includes libraries,
backends, bindings, examples, tests, benchmarks, and generated project code.
Third-party libraries and archived third-party compiler output are exempt;
project-owned glue under a dependency directory is not automatically exempt.
Build reality: the rule is about raising, not about try/catch — the scanner
forbids only the tokens throw, rethrow_exception, throw_with_nested,
__cxa_throw, _CxxThrowException, throws. xmake targets compile with
exceptions = "no-cxx" plus _HAS_EXCEPTIONS=0 on Windows unless a target sets
enable_exception = true (scripts/xmake_func.lua:345-356); the only targets that do are
src/py (src/py/xmake.lua:23) and examples/extension/clangcxx_compiler
(examples/extension/clangcxx_compiler/xmake.lua:4). The CMake build disables nothing and
adds /EHsc for clang-cl (src/CMakeLists.txt:34), so catch at integration boundaries
(src/backends/remote/remote_server.cpp, src/py/export_dlpack.cpp) still compiles.
- Use
LUISA_ASSERTfor fatal preconditions andLUISA_ERRORfor unconditional failures, with an explicit<luisa/core/logging.h>include. Use a literal format string for dynamic messages, such asLUISA_ERROR("{}", message). - Preserve recoverable API contracts with explicit error/status results and propagate failures before consuming invalid values. Do not turn compilation rejection, protocol errors, or Python validation errors into process aborts merely to remove an exception. Python bindings can use the Python C API error indicator and a null return from a C API entry point.
- Preserve cleanup with RAII. Catching a third-party exception at an integration boundary is allowed; do not remove that boundary or enable exceptions on an otherwise exception-free target to accommodate project-owned raising code.
- Test expected fatal failures in a separate process; do not use
expect(throws(...))for a function that now reports through Luisa fatal checks. See the test skill.
Run python scripts/check_cpp_no_throw.py (no arguments; it scans every tracked
.c/.cpp/.h/... file via git ls-files) to check the rule locally. Its third-party
exemptions are the explicit VENDORED_DIRECTORIES/VENDORED_FILES lists in the script.
CI runs it as the no-project-exceptions job of .github/workflows/check-cpp-style.yml
— that job is the only C++ style check in CI. Python raise and other host-language
error handling remain governed by their own API contracts.
Integer Types
Prefer fixed-width integer types:
- Use:
int32_t,uint32_t,int64_t,uint64_t,int16_t,uint16_t,int8_t,uint8_t size_tis acceptable for sizes/indices per STL convention.- Prefer
std::bytefor raw byte data. - Avoid
unsigned int,long long,unsigned long,short, andcharfor arithmetic. The project defines its own short aliases ininclude/luisa/core/basic_traits.h:47-56—luisa::uint = uint32_t,luisa::ushort = uint16_t,luisa::byte = int8_t,luisa::ubyte = uint8_t,luisa::slong = long long,luisa::ulong = unsigned long long— andluisa::uintis the dominant spelling in public headers, so keep using them where the surrounding API already does; do not invent new aliases. - GPU-side vector types (
int3,uint3,float2/float3/float4, …) areluisa::Vector<T, N>aliases produced byLUISA_MAKE_VECTOR_TYPESininclude/luisa/core/basic_types.h:119-140.
Verification
After editing C++ files:
# Syntax + clang-tidy diagnostics through the project checker (--clang-tidy is opt-in)
python scripts/check_cpp_syntax.py src/core/logging.cpp --clang-tidy
# Check formatting (dry run; replace --dry-run with -i to apply) — not enforced by CI
clang-format --dry-run --Werror src/core/logging.cpp
# Run clang-tidy on a specific file (build/compile_commands.json)
clang-tidy -p build src/core/logging.cpp
# Exception-raising scan (no arguments)
python scripts/check_cpp_no_throw.pyWhen changing build-affecting files, configure and build a relevant target:
xmake f -m debug -c
xmake build <target>Resources
.clang-format— project-root formatter config (referenced above; not copied into this skill)..clang-tidy— project-root static-analysis config (referenced above; not copied into this skill)..clangd— project-root configuration for clangd diagnostics (CompileFlags.Add/Remove, suppressions); not copied into this skill.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

