Magic-Mirror/llvm-capstone
1
0
Fork 0
mirror of https://github.com/capstone-engine/llvm-capstone.git synced 2024-12-03 19:32:35 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity
1b29a848ff
llvm-capstone/flang/docs/PullRequestChecklist.md
Richard Barton 271a7bb144 [flang] Add new documentation main page 
Add a new index page to be the Flang documentation mainpage instead of
Overview.md, which jumps straight into the compiler Design. The index file
needs to be in .rst format to use the toctree directive to create table of
contents.

Also use the sphinx_markdown_tables extension to generate html tables form
markdown.

A number of additional style changes to the existing docs were needed to make
this work well:
 * Convert all headings to the # style, which works better with toctree's
   titlesonly option. Ensure that there is only one top-level heading per
   document.
 * Add a title to documents that don't have one for rendering on the index.
 * Convert the grammar docs from .txt to .md. for better rendering
 * Fixed broken link to a section in another document - sphinx does not seem to
   support anchor links in markdown files.

Depends on D87226

Reviewed By: sameeranjoshi

Differential Revision: https://reviews.llvm.org/D87242
2020-09-11 14:19:51 +01:00

2.4 KiB
Raw Blame History

Pull request checklist

Please review the following items before submitting a pull request. This list can also be used when reviewing pull requests.

  • Verify that new files have a license with correct file name.
  • Run git diff on all modified files to look for spurious changes such as #include <iostream>.
  • If you added code that causes the compiler to emit a new error message, make sure that you also added a test that causes that error message to appear and verifies its correctness.
  • Annotate the code and tests with appropriate references to constraint and requirement numbers from the Fortran standard. Do not include the text of the constraint or requirement, just its number.
  • Alphabetize arbitrary lists of names.
  • Check dereferences of pointers and optionals where necessary.
  • Ensure that the scopes of all functions and variables are as local as possible.
  • Try to make all functions fit on a screen (40 lines).
  • Build and test with both GNU and clang compilers.
  • When submitting an update to a pull request, review previous pull request comments and make sure that you've actually made all of the changes that were requested.

Follow the style guide

The following items are taken from the C++ style guide. But even though I've read the style guide, they regularly trip me up.

  • Run clang-format using the git-clang-format script from LLVM HEAD.
  • Make sure that all source lines have 80 or fewer characters. Note that clang-format will do this for most code. But you may need to break up long strings.
  • Review declarations for proper use of constexpr and const.
  • Follow the C++ naming guidelines
  • Ensure that the names evoke their purpose and are consistent with existing code.
  • Used braced initializers.
  • Review pointer and reference types to make sure that you're using them appropriately. Note that the C++ style guide contains a section that describes all of the pointer types along with their characteristics.
  • Declare non-member functions static when possible. Prefer static functions over functions in anonymous namespaces.