proactive at catching incoming bugs in their components and dealing with them
promptly.
+Please be aware that all public LLVM mailing lists are public and archived, and
+that notices of confidentiality or non-disclosure cannot be respected.
+
.. _patch:
.. _one-off patches:
-Making a Patch
---------------
+Making and Submitting a Patch
+-----------------------------
When making a patch for review, the goal is to make it as easy for the reviewer
to read it as possible. As such, we recommend that you:
script, please separate out those changes into a separate patch from the rest
of your changes.
+Once your patch is ready, submit it by emailing it to the appropriate project's
+commit mailing list (or commit it directly if applicable). Alternatively, some
+patches get sent to the project's development list or component of the LLVM bug
+tracker, but the commit list is the primary place for reviews and should
+generally be preferred.
+
When sending a patch to a mailing list, it is a good idea to send it as an
*attachment* to the message, not embedded into the text of the message. This
ensures that your mailer will not mangle the patch when it sends it (e.g. by
a file inline, making it difficult to work with for reviewers using that
program.
+When submitting patches, please do not add confidentiality or non-disclosure
+notices to the patches themselves. These notices conflict with the `LLVM
+License`_ and may result in your contribution being excluded.
+
.. _code review:
Code Reviews
#. All developers are required to have significant changes reviewed before they
are committed to the repository.
-#. Code reviews are conducted by email, usually on the llvm-commits list.
+#. Code reviews are conducted by email on the relevant project's commit mailing
+ list, or alternatively on the project's development list or bug tracker.
#. Code can be reviewed either before it is committed or after. We expect major
changes to be reviewed before being committed, but smaller changes (or
directory. The appropriate sub-directory should be selected (see the
:doc:`Testing Guide <TestingGuide>` for details).
-* Test cases should be written in `LLVM assembly language <LangRef.html>`_
- unless the feature or regression being tested requires another language
- (e.g. the bug being fixed or feature being implemented is in the llvm-gcc C++
- front-end, in which case it must be written in C++).
+* Test cases should be written in :doc:`LLVM assembly language <LangRef>`.
* Test cases, especially for regressions, should be reduced as much as possible,
- by `bugpoint <Bugpoint.html>`_ or manually. It is unacceptable to place an
+ by :doc:`bugpoint <Bugpoint>` or manually. It is unacceptable to place an
entire failing program into ``llvm/test`` as this creates a *time-to-test*
burden on all developers. Please keep them short.
progress. The developer is welcome to re-commit the change after the problem has
been fixed.
+.. _commit messages:
+
+Commit messages
+---------------
+
+Although we don't enforce the format of commit messages, we prefer that
+you follow these guidelines to help review, search in logs, email formatting
+and so on. These guidelines are very similar to rules used by other open source
+projects.
+
+Most importantly, the contents of the message should be carefully written to
+convey the rationale of the change (without delving too much in detail). It
+also should avoid being vague or overly specific. For example, "bits were not
+set right" will leave the reviewer wondering about which bits, and why they
+weren't right, while "Correctly set overflow bits in TargetInfo" conveys almost
+all there is to the change.
+
+Below are some guidelines about the format of the message itself:
+
+* Separate the commit message into title, body and, if you're not the original
+ author, a "Patch by" attribution line (see below).
+
+* The title should be concise. Because all commits are emailed to the list with
+ the first line as the subject, long titles are frowned upon. Short titles
+ also look better in `git log`.
+
+* When the changes are restricted to a specific part of the code (e.g. a
+ back-end or optimization pass), it is customary to add a tag to the
+ beginning of the line in square brackets. For example, "[SCEV] ..."
+ or "[OpenMP] ...". This helps email filters and searches for post-commit
+ reviews.
+
+* The body, if it exists, should be separated from the title by an empty line.
+
+* The body should be concise, but explanatory, including a complete
+ reasoning. Unless it is required to understand the change, examples,
+ code snippets and gory details should be left to bug comments, web
+ review or the mailing list.
+
+* If the patch fixes a bug in bugzilla, please include the PR# in the message.
+
+* `Attribution of Changes`_ should be in a separate line, after the end of
+ the body, as simple as "Patch by John Doe.". This is how we officially
+ handle attribution, and there are automated processes that rely on this
+ format.
+
+* Text formatting and spelling should follow the same rules as documentation
+ and in-code comments, ex. capitalization, full stop, etc.
+
+* If the commit is a bug fix on top of another recently committed patch, or a
+ revert or reapply of a patch, include the svn revision number of the prior
+ related commit. This could be as simple as "Revert rNNNN because it caused
+ PR#".
+
+For minor violations of these recommendations, the community normally favors
+reminding the contributor of this policy over reverting. Minor corrections and
+omissions can be handled by sending a reply to the commits mailing list.
+
Obtaining Commit Access
-----------------------
---------------------
When a developer begins a major new project with the aim of contributing it back
-to LLVM, s/he should inform the community with an email to the `llvmdev
+to LLVM, they should inform the community with an email to the `llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_ email list, to the extent
possible. The reason for this is to:
Attribution of Changes
----------------------
-We believe in correct attribution of contributions to their contributors.
-However, we do not want the source code to be littered with random attributions
-"this code written by J. Random Hacker" (this is noisy and distracting). In
-practice, the revision control system keeps a perfect history of who changed
-what, and the CREDITS.txt file describes higher-level contributions. If you
-commit a patch for someone else, please say "patch contributed by J. Random
-Hacker!" in the commit message.
+When contributors submit a patch to an LLVM project, other developers with
+commit access may commit it for the author once appropriate (based on the
+progression of code review, etc.). When doing so, it is important to retain
+correct attribution of contributions to their contributors. However, we do not
+want the source code to be littered with random attributions "this code written
+by J. Random Hacker" (this is noisy and distracting). In practice, the revision
+control system keeps a perfect history of who changed what, and the CREDITS.txt
+file describes higher-level contributions. If you commit a patch for someone
+else, please follow the attribution of changes in the simple manner as outlined
+by the `commit messages`_ section. Overall, please do not add contributor names
+to the source code.
+
+Also, don't commit patches authored by others unless they have submitted the
+patch to the project or you have been authorized to submit them on their behalf
+(you work together and your company authorized you to contribute the patches,
+etc.). The author should first submit them to the relevant project's commit
+list, development list, or LLVM bug tracker component. If someone sends you
+a patch privately, encourage them to submit it to the appropriate list first.
+
+
+IR Backwards Compatibility
+--------------------------
+
+When the IR format has to be changed, keep in mind that we try to maintain some
+backwards compatibility. The rules are intended as a balance between convenience
+for llvm users and not imposing a big burden on llvm developers:
+
+* The textual format is not backwards compatible. We don't change it too often,
+ but there are no specific promises.
+
+* The bitcode format produced by a X.Y release will be readable by all following
+ X.Z releases and the (X+1).0 release.
+
+* Newer releases can ignore features from older releases, but they cannot
+ miscompile them. For example, if nsw is ever replaced with something else,
+ dropping it would be a valid way to upgrade the IR.
+
+* Debug metadata is special in that it is currently dropped during upgrades.
-Overall, please do not add contributor names to the source code.
+* Non-debug metadata is defined to be safe to drop, so a valid way to upgrade
+ it is to drop it. That is not very user friendly and a bit more effort is
+ expected, but no promises are made.
.. _copyright-license-patents:
cannot be moved from the LLVM core to libc++ without the copyright owner's
permission.
-Note that the LLVM Project does distribute llvm-gcc and dragonegg, **which are
-GPL.** This means that anything "linked" into llvm-gcc must itself be compatible
+Note that the LLVM Project does distribute dragonegg, **which is
+GPL.** This means that anything "linked" into dragonegg must itself be compatible
with the GPL, and must be releasable under the terms of the GPL. This implies
-that **any code linked into llvm-gcc and distributed to others may be subject to
+that **any code linked into dragonegg and distributed to others may be subject to
the viral aspects of the GPL** (for example, a proprietary code generator linked
-into llvm-gcc must be made available under the GPL). This is not a problem for
+into dragonegg must be made available under the GPL). This is not a problem for
code already distributed under a more liberal license (like the UIUC license),
and GPL-containing subprojects are kept in separate SVN repositories whose
LICENSE.txt files specifically indicate that they contain GPL code.