Lines Matching +full:llvm +full:- +full:project
4 LLVM Developer Policy
13 This document contains the LLVM Developer Policy which defines the project's
16 distributed nature of LLVM's development. By stating the policy in clear terms,
17 we hope each developer can know ahead of time what to expect when making LLVM
18 contributions. This policy covers all llvm.org subprojects, including Clang,
23 #. Attract both users and developers to the LLVM project.
29 #. Establish awareness of the project's :ref:`copyright, license, and patent
30 policies <copyright-license-patents>` with contributors to the project.
32 This policy is aimed at frequent contributors to LLVM. People interested in
33 contributing one-off patches can do so in an informal way by sending them to the
34 `llvm-commits mailing list
35 <http://lists.llvm.org/mailman/listinfo/llvm-commits>`_ and engaging another
41 This section contains policies that pertain to frequent LLVM developers. We
42 always welcome `one-off patches`_ from people who do not routinely contribute to
43 LLVM, but we expect more from frequent contributors to keep the system as
44 efficient as possible for everyone. Frequent LLVM contributors are expected to
45 meet the following requirements in order for LLVM to maintain a high standard of
49 -------------
51 Developers should stay informed by reading the `LLVM Discourse forums`_ and subscribing
55 are interested in and watching the flow of the project as a whole.
57 Contibutions to the project are made through :ref:`GitHub Pull Requests <github-reviews>`.
59 one of the `pr-subscribers-* <https://github.com/orgs/llvm/teams?query=pr-subscribers>`_
60 GitHub teams. This `mapping <https://github.com/llvm/llvm-project/blob/main/.github/new-prs-labeler.yml>`_
64 such as `llvm-commits
65 <http://lists.llvm.org/mailman/listinfo/llvm-commits>`_, `cfe-commits
66 <http://lists.llvm.org/mailman/listinfo/cfe-commits>`_, or `lldb-commits
67 <http://lists.llvm.org/mailman/listinfo/lldb-commits>`_.
69 Missing features and bugs are tracked through our `GitHub issue tracker <https://github.com/llvm/llvm-project/issues>`_
72 one of the `issue-subscribers-* <https://github.com/orgs/llvm/teams?query=issue-subscribers>`_
74 You may also subscribe to the `llvm-bugs
75 <http://lists.llvm.org/mailman/listinfo/llvm-bugs>`_ email list to keep track
76 of bugs and enhancements occurring in the entire project. We really appreciate people
80 Please be aware that all public LLVM mailing lists and discourse forums are public and archived, and
81 that notices of confidentiality or non-disclosure cannot be respected.
84 .. _one-off patches:
87 -----------------------------
93 of LLVM. This makes it easy to apply the patch. For information on how to
101 :ref:`GitHub Pull Request <github-reviews>` for
104 When submitting patches, please do not add confidentiality or non-disclosure
105 notices to the patches themselves. These notices conflict with the LLVM
108 .. _github-email-address:
111 ---------------
113 The LLVM project uses email to communicate to contributors outside of the
118 Therefore, the LLVM community requires contributors to have a public
126 ------------
128 LLVM has a code-review policy. Code review is one way to increase the quality of
129 software. Please see :doc:`CodeReview` for more information on LLVM's code-review
135 -----------------------------------
139 to be removed in the future, removing an already-deprecated feature, upgrading a
146 Phabricator is deprecated and is available in read-only mode,
147 for new code contributions use :ref:`GitHub Pull Requests <github-reviews>`.
157 * `Clang vendors <https://reviews.llvm.org/project/members/113/>`_
158 * `libc++ vendors <https://reviews.llvm.org/project/members/109/>`_
161 "Join Project" link on the vendor's "Members" page in Phabricator.
165 section of the project's release notes. The release note should have
173 `Announcements <https://discourse.llvm.org/c/announce/>`_ channel on
174 Discourse. The post should be tagged with the ``potentially-breaking`` label
175 and a label specific to the project (such as ``clang``, ``llvm``, etc). This
176 is another mechanism by which we can give pre-release notice to users about
177 potentially disruptive changes. It is a lower-traffic alternative to the
179 with the ``potentially-breaking`` label, go to your user preferences page in
181 ``Notifications->Tags``.
186 -----------
188 The LLVM Project aims to evolve features quickly while continually being in a
189 release-ready state. In order to accomplish this, the project needs volunteers
190 willing to do the less glamorous work to ensure we produce robust, high-quality
195 Community members can find active and inactive maintainers for a project in the
196 ``Maintainers.rst`` file at the root directory of the individual project.
199 within an area of a project:
201 * ensure that commits receive high-quality review, either by the maintainer
208 * aid release managers with backporting and other release-related
213 Each top-level project in the monorepo will specify one or more
215 met for that project. This role is like any other maintainer role,
216 except the responsibilities span the project rather than a limited area
217 within the project. If you cannot reach a maintainer or don't know which
219 to reach out to. If a project has no active lead maintainers, it may be a
222 project should be discontinued.
224 All contributors with commit access to the LLVM Project are eligible to be a
229 the LLVM Community Code of Conduct, and
242 the same project vouches for their ability to perform the responsibilities and
246 maintainers" section of the ``Maintainers.rst`` file for the project, or remove
250 maintainer within that project with agreement from one other active maintainer
251 within that project. If there is only one active maintainer for a project,
253 and future direction for the project. However, please discuss the situation
263 they will be re-accepted so long as at least one maintainer in the same project
269 ----------
274 * All feature and regression test cases are added to the ``llvm/test``
275 directory. The appropriate sub-directory should be selected (see the
278 * Test cases should be written in :doc:`LLVM assembly language <LangRef>`.
282 entire failing program into ``llvm/test`` as this creates a *time-to-test*
290 Note that llvm/test and clang/test are designed for regression and small feature
292 etc) should be added to the ``llvm-test`` test suite. The llvm-test suite is
297 -------------
299 Many projects in LLVM communicate important changes to users through release
300 notes, typically found in ``docs/ReleaseNotes.rst`` for the project. Changes to
301 a project that are user-facing, or that users may wish to know about, should be
302 added to the project's release notes at the author's or code reviewer's
307 * Adding, removing, or modifying command-line options.
309 * Fixing a bug that potentially has significant user-facing impact (please link
319 announced in the `Announcements <https://discourse.llvm.org/c/announce/>`_
326 -------
331 #. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
338 #. Code must pass the ``llvm/test`` test suite.
340 #. The code must not cause regressions on a reasonable subset of llvm-test,
343 might be something like "``llvm-test/MultiSource/Benchmarks``".
355 * The changes should not cause any correctness regressions in the ``llvm-test``
359 LLVM tools.
362 compiled by LLVM on all applicable targets.
364 * You are expected to address any `GitHub Issues <https://github.com/llvm/llvm-project/issues>`_ that
377 progress. The developer is welcome to re-commit the change after the problem has
383 ---------------
404 ``git commit --amend --author="John Doe <jdoe@llvm.org>"`` to correct the
406 information including the method we used for attribution before the project
410 tag 'Co-authored-by:' to list the additional authors
411 <https://github.blog/2018-01-29-commit-together-with-co-authors/>`_.
418 back-end or optimization pass), it is customary to add a tag to the
420 or "[OpenMP] ...". This helps email filters and searches for post-commit
431 and in-code comments, ex. capitalization, full stop, etc.
439 `here <https://www.llvm.org/docs/Phabricator.html#committing-a-change>`__.
442 `here <https://llvm.org/docs/BugLifeCycle.html#resolving-closing-bugs>`__.
448 message self-explanatory. Note that such non-public links should not be
458 ----------------------
479 fixed patch - possibly after another round of review if warranted.
483 * If you receive substantial :ref:`post-commit review <post_commit_review>`
513 patch was reverted, and helps others following llvm-commits track context.
534 * When re-applying a reverted patch, the commit message should be updated to
540 -----------------------
543 If you would like commit access, please use this `link <https://github.com/llvm/llvm-project/issues/new?title=Request%20Commit%20Access%20For%20%3Cuser%3E&body=%23%23%23%20Why%20Are%20you%20requesting%20commit%20access%20?>`_ to file
548 `Invitation Link <https://github.com/orgs/llvm/invitation>`_ directly. Once
557 on a commits mailing list soon after the commit lands (e.g. llvm-commits_).
564 #. You are granted *commit-after-approval* to all parts of LLVM. For
569 obvious. This is clearly a subjective decision --- we simply expect you to
572 changes. Avoid committing formatting- or whitespace-only changes outside of
580 #. You are allowed to commit patches without approval to those portions of LLVM
597 ---------------------
599 When a developer begins a major new project with the aim of contributing it back
600 to LLVM, they should inform the community with a post to the `LLVM Discourse forums`_, to the extent
603 #. keep the community informed about future changes to LLVM,
611 The design of LLVM is carefully controlled to ensure that all the pieces fit
613 change to the way LLVM works or want to add a major new extension, it is a good
618 as a series of `incremental changes`_, not as a long-term development branch.
623 -----------------------
625 In the LLVM project, we do all significant changes as a series of incremental
626 patches. We have a strong dislike for huge changes or long-term development
627 branches. Long-term development branches have a number of drawbacks:
645 To address these problems, LLVM uses an incremental development style and we
654 * The remaining inter-related work should be decomposed into unrelated sets of
678 ----------------------
680 When contributors submit a patch to an LLVM project, other developers with
687 file describes higher-level contributions. If you commit a patch for someone
693 patch to the project or you have been authorized to submit them on their behalf
695 etc.). The author should first submit them to the relevant project's commit
696 list, development list, or LLVM bug tracker component. If someone sends you
706 ----
710 :ref:`LLVM Community Code of Conduct` in LLVM project spaces. Contributions of
720 conduct@llvm.org for advice.
726 --------------------------
730 for llvm users and not imposing a big burden on llvm developers:
738 * The current LLVM version supports loading any bitcode since version 3.0.
741 ``compatibility-X.Y.ll``. The corresponding bitcode file should be assembled
742 using the X.Y build and committed as ``compatibility-X.Y.ll.bc``.
750 * Non-debug metadata is defined to be safe to drop, so a valid way to upgrade
755 -------------
772 * Including new things into the API: If an LLVM subcomponent has a C API already
775 `LLVM Discourse forums`_ for design and maintainability feedback prior to implementation.
779 project how the C API is changing and evolving.
784 -------------------------------
786 We intend to require newer toolchains as time goes by. This means LLVM's
788 toolchains to build LLVM can be painful for those building LLVM; therefore, it
791 * It is a general goal to support LLVM and GCC versions from the last 3 years
792 at a minimum. This time-based guideline is not strict: we may support much
795 * An RFC is sent to the `LLVM Discourse forums`_
797 - Detail upsides of the version increase (e.g. which newer C++ language or
798 library features LLVM should use; avoid miscompiles in particular compiler
800 - Detail downsides on important platforms (e.g. Ubuntu LTS status).
804 softer transition path for developers compiling LLVM, because the
806 step: LLVM still doesn't have code which requires the new toolchains, but it
807 soon will. If you compile LLVM but don't read the forums, we should
810 * Ensure that at least one LLVM release has had this soft-error. Not all
811 developers compile LLVM top-of-tree. These release-bound developers should
814 * Turn the soft-error into a hard-error after said LLVM release has branched.
819 * Start using the new features in LLVM's codebase.
822 <https://discourse.llvm.org/t/rfc-migrating-past-c-11/50943>`_ and the
823 `corresponding change <https://reviews.llvm.org/D57264>`_.
825 .. _ci-usage:
828 --------------------------
830 The main continuous integration (CI) tool for the LLVM project is the
831 `LLVM Buildbot <https://lab.llvm.org/buildbot/>`_. It uses different *builders*
832 to cover a wide variety of sub-projects and configurations. The builds are
838 branches (aka post-merge testing). This also means it's okay to break the build
851 * Comment on the code review in `GitHub <https://github.com/llvm/llvm-project/pulls>`_
868 `Infrastructure Working Group <mailto:iwg@llvm.org>`_.
870 .. _new-llvm-components:
872 Introducing New Components into LLVM
875 The LLVM community is a vibrant and exciting place to be, and we look to be
882 components into the LLVM world, depending on the degree of detail and
888 to discussing unusual cases as well - just start an RFC thread on the
889 `LLVM Discourse forums`_.
892 -------------------
894 LLVM is very receptive to new targets, even experimental ones, but a number of
895 problems can appear when adding new large portions of code, and back-ends are
901 emergent problems in-tree is problematic for a variety of reasons. For these
903 proven stable, and later moved to non-experimental.
914 The basic rules for a back-end to be upstreamed in **experimental** mode are:
923 bugs, answering the LLVM community's questions and making sure the new
929 changes in how the IR behaves or should be formed by the front-ends,
939 (either free or cheap enough) - preferably both. This allows
943 In addition, the rules for a back-end to be promoted to **official** are:
947 period is to make sure that the back-end and the target community can
956 well documented). The build target ``check-all`` must pass with the
957 new target built, and where applicable, the ``test-suite`` must also
962 the target requires no additional buildbots (ex. ``check-all`` covers
964 is, the more the LLVM community will embrace it.
977 status, but also markers to define bit-rot, and will be used to clean up the
980 Those wishing to add a new target to LLVM must follow the procedure below:
985 2. Send a request for comment (RFC) to the `LLVM Discourse forums`_ describing
990 3. Once the response is positive, the LLVM community can start reviewing the
995 clang and LLVM. The following patches add TableGen infrastructure to describe
1008 the `LLVM Discourse forums`_.
1010 Adding an Established Project To the LLVM Monorepo
1011 --------------------------------------------------
1013 The `LLVM monorepo <https://github.com/llvm/llvm-project>`_ is the centerpoint
1014 of development in the LLVM world, and has all of the primary LLVM components,
1015 including the LLVM optimizer and code generators, Clang, LLDB, etc. `Monorepos
1017 allow atomic commits to the project, simplify CI, and make it easier for
1022 things to the LLVM monorepo needs to be very high - code that is added to this
1026 * Must be generally aligned with the mission of the LLVM project to advance
1034 * Should have CI to catch breakage within the project itself or due to
1035 underlying LLVM dependencies.
1038 * Must be proposed through the LLVM RFC process, and have its addition approved
1039 by the LLVM community - this ultimately mediates the resolution of the
1042 If you have a project that you think would make sense to add to the LLVM
1043 monorepo, please start an RFC topic on the `LLVM Discourse forums`_ to kick off
1044 the discussion. This process can take some time and iteration - please don’t
1047 If you have an earlier stage project that you think is aligned with LLVM, please
1051 -----------------------
1053 The burden to add a new project to the LLVM monorepo is intentionally very high,
1055 foster these sorts of projects, LLVM supports an "incubator" process that is
1057 new top-level and sub-projects to reach a critical mass before they have enough
1060 to projects under the LLVM umbrella.
1062 Projects which can be considered for the LLVM incubator meet the following
1065 * Must be generally aligned with the mission of the LLVM project to advance
1076 * Should have a feasible path to eventually graduate as a dedicated top-level
1077 or sub-project within the `LLVM monorepo
1078 <https://github.com/llvm/llvm-project>`_.
1079 * Should include a notice (e.g. in the project README or web page) that the
1080 project is in ‘incubation status’ and is not included in LLVM releases (see
1082 * Must be proposed through the LLVM RFC process, and have its addition
1083 approved by the LLVM community - this ultimately mediates the resolution of
1086 That said, the project need not have any code to get started, and need not have
1093 When approved, the llvm-admin group can grant the new project:
1094 * A new repository in the LLVM Github Organization - but not the LLVM monorepo.
1095 * New mailing list, discourse forum, and/or discord chat hosted with other LLVM
1097 * Other infrastructure integration can be discussed on a case-by-case basis.
1099 Graduation to the mono-repo would follow existing processes and standards for
1100 becoming a first-class part of the monorepo. Similarly, an incubating project
1102 and when this comes up, please start an RFC discussion on the `LLVM Discourse forums`_.
1104 This process is very new - please expect the details to change, it is always
1105 safe to ask on the `LLVM Discourse forums`_ about this.
1107 Suggested disclaimer for the project README and the main project web page:
1111 This project is participating in the LLVM Incubator process: as such, it is
1112 not part of any official LLVM release. While incubation status is not
1114 does indicate that the project is not yet endorsed as a component of LLVM.
1116 .. _copyright-license-patents:
1124 are not lawyers --- please seek legal counsel from a licensed attorney.
1126 This section addresses the issues of copyright, license and patents for the LLVM
1127 project. The copyright for the code is held by the contributors of
1129 namely the Apache-2.0 with LLVM-exception license, which includes a copyright
1130 and `patent license`_. When you contribute code to the LLVM project, you
1134 to the codebase. However, this may only be done with approval of the LLVM
1136 process to take at least 4-6 weeks. If you would like to contribute code
1138 you want to contribute and email board@llvm.org requesting a review.
1141 `LLVM Discourse forums`_. However,
1145 .. _LLVM Discourse forums: https://discourse.llvm.org
1148 ---------
1150 The LLVM project does not collect copyright assignments, which means that the
1151 copyright for the code in the project is held by the respective contributors.
1157 Because the LLVM project does not require copyright assignments, changing the
1158 LLVM license requires tracking down the
1159 contributors to LLVM and getting them to agree that a license change is
1161 is good for the project, because contributors do not have to fear that their
1167 The LLVM project does not accept contributions that include in-source copyright
1168 notices except where such notices are part of a larger external project being
1171 LLVM source code lives for a long time and is edited by many people, the best
1177 -----------
1179 The last paragraph notwithstanding, the LLVM Project is in the middle of a large
1185 * Some contributions were not submitted to LLVM due to concerns that
1186 the patent grant required by the project was overly broad.
1187 * The patent grant was unique to the LLVM Project, not written by a lawyer, and
1190 The scope of relicensing is all code that is considered part of the LLVM
1191 project, including the main LLVM repository, runtime libraries (compiler_rt,
1195 remain as it is. This code isn't developed as part of the LLVM project, it
1196 is used by LLVM.
1197 * Some subprojects are impractical or uninteresting to relicense (e.g. llvm-gcc
1198 and dragonegg). These will be split off from the LLVM project (e.g. to
1202 To relicense LLVM, we will be seeking approval from all of the copyright holders
1205 and challenging project which will take a significant amount of time to
1208 Starting on 2024-06-01 (first of June 2024), new contributions only need to
1209 be covered by the new LLVM license, i.e. Apache-2.0 WITH LLVM-exception.
1210 Before this date, the project required all contributions to be made under
1213 If you are a contributor to LLVM with contributions committed before 2019-01-19
1215 https://foundation.llvm.org/docs/relicensing/, under section "Individual
1221 New LLVM Project License Framework
1222 ----------------------------------
1224 Contributions to LLVM are licensed under the `Apache License, Version 2.0
1225 <https://www.apache.org/licenses/LICENSE-2.0>`_, with two limited
1226 exceptions intended to ensure that LLVM is very permissively licensed.
1227 Collectively, the name of this license is "Apache 2.0 License with LLVM
1232 ---- LLVM Exceptions to the Apache 2.0 License ----
1249 We intend to keep LLVM perpetually open source and available under a permissive
1250 license - this fosters the widest adoption of LLVM by
1251 **allowing commercial products to be derived from LLVM** with few restrictions
1253 particular, LLVM's license is not a "copyleft" license like the GPL.
1255 The "Apache 2.0 License with LLVM exceptions" allows you to:
1257 * freely download and use LLVM (in whole or in part) for personal, internal, or
1259 * include LLVM in packages or distributions you create.
1260 * combine LLVM with code licensed under every other major open source
1262 * make changes to LLVM code without being required to contribute it back
1263 to the project - contributions are appreciated though!
1267 * You must retain the copyright notice if you redistribute LLVM: You cannot
1269 * Binaries that include LLVM must reproduce the copyright notice (e.g. in an
1270 included README file or in an "About" box), unless the LLVM code was added as
1271 a by-product of compilation. For example, if an LLVM runtime library like
1274 * You can't use our names to promote your products (LLVM derived or not) -
1275 though you can make truthful statements about your use of the LLVM code,
1277 * There's no warranty on LLVM at all.
1279 We want LLVM code to be widely used, and believe that this provides a model that
1280 is great for contributors and users of the project. For more information about
1282 <http://www.apache.org/foundation/license-faq.html>`_, maintained by the
1283 Apache Project.
1288 -------
1291 contributors of code to the project contribute the rights to use any of
1294 from anyone who files a patent lawsuit about code in LLVM - this protects the
1300 <http://www.apache.org/foundation/license-faq.html>`_ explains this scope using
1339 ------------------------
1344 More than 99% of all contributions made to LLVM are covered by the Apache-2.0
1345 WITH LLVM-exception license. A small portion of LLVM code remains exclusively
1346 covered by the legacy license. Contributions after 2024-06-01 are covered
1349 We intend to keep LLVM perpetually open source and to use a permissive open
1351 LLVM is available under the `University of Illinois/NCSA Open Source License
1352 <http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down to
1355 * You can freely distribute LLVM.
1356 * You must retain the copyright notice if you redistribute LLVM.
1357 * Binaries derived from LLVM must reproduce the copyright notice (e.g. in an
1359 * You can't use our names to promote your LLVM derived products.
1360 * There's no warranty on LLVM at all.
1362 We believe this fosters the widest adoption of LLVM because it **allows
1363 commercial products to be derived from LLVM** with few restrictions and without
1364 a requirement for making any derived works also open source (i.e. LLVM's
1366 `License <http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
1369 In addition to the UIUC license, the runtime library components of LLVM
1371 <http://www.opensource.org/licenses/mit-license.php>`_, which does not contain
1379 to move code from (e.g.) libc++ to the LLVM core without concern, but that code
1380 cannot be moved from the LLVM core to libc++ without the copyright owner's
1386 --------------------------
1397 As such, the LLVM policy is that contributors are permitted to use artificial
1399 to license that code under the project license. Contributions found to violate
1402 While the LLVM project has a liberal policy on AI tool use, contributors are
1407 does not understand is not a good use of limited project resources.