Lines Matching +full:docs +full:- +full:polly +full:- +full:html
30 policies <copyright-license-patents>` with contributors to the project.
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
42 always welcome `one-off patches`_ from people who do not routinely contribute to
49 -------------
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
81 that notices of confidentiality or non-disclosure cannot be respected.
84 .. _one-off patches:
87 -----------------------------
101 :ref:`GitHub Pull Request <github-reviews>` for
104 When submitting patches, please do not add confidentiality or non-disclosure
108 .. _github-email-address:
111 ---------------
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>`.
174 Discourse. The post should be tagged with the ``potentially-breaking`` label
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 -----------
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
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
263 they will be re-accepted so long as at least one maintainer in the same project
269 ----------
275 directory. The appropriate sub-directory should be selected (see the
282 entire failing program into ``llvm/test`` as this creates a *time-to-test*
292 etc) should be added to the ``llvm-test`` test suite. The llvm-test suite is
297 -------------
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
307 * Adding, removing, or modifying command-line options.
309 * Fixing a bug that potentially has significant user-facing impact (please link
326 -------
331 #. Code must adhere to the `LLVM Coding Standards <CodingStandards.html>`_.
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``
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
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
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
597 ---------------------
618 as a series of `incremental changes`_, not as a long-term development branch.
623 -----------------------
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:
654 * The remaining inter-related work should be decomposed into unrelated sets of
678 ----------------------
687 file describes higher-level contributions. If you commit a patch for someone
706 ----
726 --------------------------
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 -------------
784 -------------------------------
792 at a minimum. This time-based guideline is not strict: we may support much
797 - Detail upsides of the version increase (e.g. which newer C++ language or
800 - Detail downsides on important platforms (e.g. Ubuntu LTS status).
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.
822 <https://discourse.llvm.org/t/rfc-migrating-past-c-11/50943>`_ and the
825 .. _ci-usage:
828 --------------------------
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>`_
870 .. _new-llvm-components:
888 to discussing unusual cases as well - just start an RFC thread on the
892 -------------------
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:
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
977 status, but also markers to define bit-rot, and will be used to clean up the
1011 --------------------------------------------------
1013 The `LLVM monorepo <https://github.com/llvm/llvm-project>`_ is the centerpoint
1022 things to the LLVM monorepo needs to be very high - code that is added to this
1039 by the LLVM community - this ultimately mediates the resolution of the
1044 the discussion. This process can take some time and iteration - please don’t
1051 -----------------------
1057 new top-level and sub-projects to reach a critical mass before they have enough
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>`_.
1083 approved by the LLVM community - this ultimately mediates the resolution of
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.
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
1104 This process is very new - please expect the details to change, it is always
1116 .. _copyright-license-patents:
1124 are not lawyers --- please seek legal counsel from a licensed attorney.
1129 namely the Apache-2.0 with LLVM-exception license, which includes a copyright
1136 process to take at least 4-6 weeks. If you would like to contribute code
1148 ---------
1167 The LLVM project does not accept contributions that include in-source copyright
1177 -----------
1192 OpenMP, etc), Polly, and all other subprojects. There are a few exceptions:
1197 * Some subprojects are impractical or uninteresting to relicense (e.g. llvm-gcc
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.
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
1222 ----------------------------------
1225 <https://www.apache.org/licenses/LICENSE-2.0>`_, with two limited
1232 ---- LLVM Exceptions to the Apache 2.0 License ----
1250 license - this fosters the widest adoption of LLVM by
1263 to the project - contributions are appreciated though!
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) -
1282 <http://www.apache.org/foundation/license-faq.html>`_, maintained by the
1288 -------
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
1352 <http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down to
1366 `License <http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
1371 <http://www.opensource.org/licenses/mit-license.php>`_, which does not contain
1386 --------------------------