Contributing

Choosing, testing and submitting a first Clang contribution (days 22–30).

AI tools and LLVM contributions

LLVM contribution work has its own rules. At the time of source review, LLVM requires human review and accountability, transparent labelling of substantial generated content, and prohibits AI tools from fixing issues labelled good first issue. Read the AI tool use policy (R16) again before selecting or submitting work. For such issues, implement and investigate the fix manually. That this website was generated with AI help does not waive the restriction.

Selecting and preparing a contribution

Choose one item with a minimal reproducer, understandable expected behavior, a likely local implementation point and tests you can run. A small patch is useful only if it resolves a real problem or adds justified coverage. Search issue and PR history before beginning. Labels can help discovery but do not prove that work is available, easy or still relevant. Select a live issue when you reach day 22, not before.

For a behavior-changing patch, show that the new regression test fails before the fix and passes after it. For a coverage-only patch, explain the gap and demonstrate that the test checks the intended property. For documentation, validate the documented workflow where feasible. Record baseline failures and limitations honestly.

Avoid a first patch involving large refactors, ABI changes, broad template deduction rules, concepts, modules or code generation for a new architecture. Useful fallbacks include reducing a report, finding the responsible code path, correcting misleading instructions or strengthening a nearby test. If expected C++ behavior remains unclear, ask with a minimal example and a specific question (R18).

Commands for Clang testing

Run from the llvm-main checkout after building test dependencies with check-clang. Replace the filename placeholder with an existing test you have located, or your new test. A complete suite can be expensive; use the focused command while iterating.

lit and check-clang

build/bin/llvm-lit -sv clang/test/SemaCXX/<test>.cpp
build/bin/llvm-lit -sv clang/test/SemaCXX
cmake --build build --target check-clang --parallel 2
git diff --check

A tiny diagnostic test can use the following content. Place it in a local scratch test under the configured Clang test tree, run it with lit, and keep it out of a PR unless it supplies useful coverage. Check the diagnostic spelling against the actual compiler under test.

Scratch -verify test

// RUN: %clang_cc1 -std=c++17 -fsyntax-only -verify %s
int f() {
  return missing; // expected-error {{use of undeclared identifier 'missing'}}
}

For other examples, annotate expected notes as well as errors using the actual compiler output. RUN substitutions belong to lit. Do not substitute the system compiler into an upstream test or treat an unsupported test as passing coverage.

Pull request readiness checklist

The problem, expected behavior and observed behavior are explicit.
The patch is based on current main and contains one logical change.
The implementation fits the existing subsystem and nearby conventions.
Regression evidence or a clear documentation/coverage rationale is included.
Relevant tests are run; commands, results and limitations are recorded.
Formatting is limited to touched code and the diff contains no unrelated files.
The description explains motivation, approach, impact and open questions.
You understand the patch and can respond to technical feedback yourself.

LLVM uses GitHub pull requests; follow the current GitHub guide (R14). Write the description in your own words. Include the issue link when applicable, the minimal example, the cause, the fix and testing. A draft should identify concrete unfinished work rather than transfer an unexplained debugging task to reviewers. Respond to review without treating day 30 as a merge deadline.

Public learning notes

Publish your own explanations and exercise code with appropriate attribution. Link to the purchased book; do not reproduce its chapters. Keep private notes private unless you deliberately publish them. Record a PR as submitted, under review, merged or closed according to its actual state.