Lines Matching +full:docs +full:- +full:changed +full:- +full:subprojects
26 - know how to use an editor,
28 - have basic C++ knowledge,
30 - know how to install software on your system,
32 - are comfortable with the command line,
34 - have basic knowledge of git.
38 -----------------------
45 $ clang -c -Wall ~/test.cc
46 test.cc:1:12: warning: all paths through this function will call itself [-Winfinite-recursion]
53 test.cc:1:12: warning: to understand recursion, you must first understand recursion [-Winfinite-recursion]
57 ------------
61 - git: to check out the LLVM source code,
63 - a C++ compiler: to compile LLVM source code. You'll want `a recent
66 - CMake: used to configure how LLVM should be built on your system,
68 - ninja: runs the C++ compiler to (re)build specific parts of LLVM,
70 - python: to run the LLVM tests.
76 $ sudo apt-get install git clang cmake ninja-build python
84 --------
87 Github <https://github.com/llvm/llvm-project>`__ in one large repository
94 $ git clone https://github.com/llvm/llvm-project.git
96 This will create a directory "llvm-project" with all of the source
97 code. (Checking out anonymously is OK - pushing commits uses a different
101 ------------------------
106 - explicit choices you make (is this a debug build?)
108 - settings detected from your system (where are libraries installed?)
110 - project structure (which files are part of 'clang'?)
112 First, create a directory to build in. Usually, this is ``llvm-project/build``.
116 $ mkdir llvm-project/build
117 $ cd llvm-project/build
123 $ cmake -G Ninja ../llvm -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PROJECTS=clang
132 Build files have been written to: /path/llvm-project/build
138 - **-G Ninja**: Tells CMake that we're going to use ninja to build, and to create
141 - **../llvm**: this is the path to the source of the "main" LLVM
144 - The two **-D** flags set CMake variables, which override
147 - **CMAKE_BUILD_TYPE=Release**: build in optimized mode, which is
157 - **LLVM_ENABLE_PROJECTS=clang**: this lists the LLVM subprojects
162 Finally, create a symlink (or copy) of ``llvm-project/build/compile-commands.json``
163 into ``llvm-project/``:
167 $ ln -s build/compile_commands.json ../
170 tools like clang-tidy, clang-query, and clangd to work in your source
175 --------------
186 The first time we build will be very slow - Clang + LLVM is a lot of
188 that have changed. When it finally finishes you should have a working
193 $ bin/clang --version
199 $ ninja check-clang
201 This is a common pattern in LLVM: check-llvm is all the checks for the core of
202 LLVM, other projects have targets like ``check-lldb``, ``check-flang`` and so on.
210 ----------
220 printed by Clang. ``*.td`` files define tables - in this case it's a list
233 ----------
241 $ bin/clang -c -Wall ~/test.cc
242 test.cc:1:12: warning: in order to understand recursion, you must first understand recursion [-Winfinite-recursion]
248 $ ninja check-clang
258 Clang :: SemaCXX/warn-infinite-recursion.cpp
269 $ vi ../clang/test/SemaCXX/warn-infinite-recursion.cpp
271 Everywhere we see ``// expected-warning{{call itself}}`` (or something similar
273 ``// expected-warning{{to understand recursion}}``.
276 iterate on a change! Instead, let's find a way to re-run just the
279 - **lit tests** (e.g. ``SemaCXX/warn-infinite-recursion.cpp``).
281 These are fancy shell scripts that run command-line tools and verify the
283 ``clang/**test**/FixIt/dereference-addressof.c``. Re-run like this:
287 $ bin/llvm-lit -v ../clang/test/SemaCXX/warn-infinite-recursion.cpp
289 - **unit tests** (e.g. ``ToolingTests/ReplacementTest.CanDeleteAllText``)
292 They live in suites like ToolingTests. Re-run like this:
296 $ ninja ToolingTests && tools/clang/unittests/Tooling/ToolingTests --gtest_filter=ReplacementTest.CanDeleteAllText
300 --------------
311 $ git checkout -b myfirstpatch
312 $ git commit -am "[clang][Diagnostic] Clarify -Winfinite-recursion message"
318 the tags for the modules you've changed, you can look at the commit history
323 $ git log --oneline ../clang/
325 Or using GitHub, for example https://github.com/llvm/llvm-project/commits/main/clang.
334 -----------------------------
336 LLVM code reviews happen through pull-request on GitHub, see the
337 :ref:`GitHub <github-reviews>` documentation for how to open
338 a pull-request on GitHub.
341 ------------------
354 --------------
356 When you open a pull-request, some automation will add a comment and
357 notify different members of the sub-projects depending on the parts you have
358 changed.
377 your branch with more commits and push to your GitHub fork of ``llvm-project``.
385 -------------------
387 In order to make LLVM a long-term sustainable effort, code needs to be
390 and push-back on design decisions that do not fit well within the
395 - be kind, and expect reviewers to be kind in return - LLVM has a
399 - be patient - understanding how a new feature fits into the
404 - if you can't agree, generally the best way is to do what the reviewer
412 ------------------------
424 ---------------
433 The pull-request will be closed and you will be notified by GitHub.
436 ---------------------
441 - you've landed 3-5 patches of larger scope than "fix a typo"
443 - you'd be willing to review changes that are closely related to yours
445 - you'd like to keep contributing to LLVM.
451 ----------------
497 -------
507 the `GitHub interface <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/reverting-a-pull-request>`__.
518 the expectations of different sub-projects may vary too.