reference, declarationdefinition
definition → references, declarations, derived classes, virtual overrides
reference to multiple definitions → definitions
unreferenced
    1
    2
    3
    4
    5
    6
    7
    8
    9
   10
   11
   12
   13
   14
   15
   16
   17
   18
   19
   20
   21
   22
   23
   24
   25
   26
   27
   28
   29
   30
   31
   32
   33
   34
   35
   36
   37
   38
   39
   40
   41
   42
   43
   44
   45
   46
   47
   48
   49
   50
   51
   52
   53
   54
   55
   56
   57
   58
   59
   60
   61
   62
   63
   64
   65
   66
   67
   68
   69
   70
   71
   72
   73
   74
   75
   76
   77
   78
   79
   80
   81
   82
   83
   84
   85
   86
   87
   88
   89
   90
   91
   92
   93
   94
   95
   96
   97
   98
   99
  100
  101
  102
  103
  104
  105
  106
  107
  108
  109
  110
  111
  112
  113
  114
  115
  116
  117
  118
  119
  120
  121
  122
  123
  124
  125
  126
  127
  128
  129
  130
  131
  132
  133
  134
  135
  136
  137
  138
  139
  140
  141
  142
  143
  144
  145
  146
  147
  148
  149
  150
  151
  152
  153
  154
  155
  156
  157
# Markdown Quickstart Template

## Introduction and Quickstart

This document is meant to get you writing documentation as fast as possible
even if you have no previous experience with Markdown. The goal is to take
someone in the state of "I want to write documentation and get it added to
LLVM's docs" and turn that into useful documentation mailed to llvm-commits
with as little nonsense as possible.

You can find this document in `docs/MarkdownQuickstartTemplate.md`. You
should copy it, open the new file in your text editor, write your docs, and
then send the new document to llvm-commits for review.

Focus on *content*. It is easy to fix the Markdown syntax
later if necessary, although Markdown tries to imitate common
plain-text conventions so it should be quite natural. A basic knowledge of
Markdown syntax is useful when writing the document, so the last
~half of this document (starting with [Example Section](#example-section)) gives examples
which should cover 99% of use cases.

Let me say that again: focus on *content*. But if you really need to verify
Sphinx's output, see `docs/README.txt` for information.

Once you have finished with the content, please send the `.md` file to
llvm-commits for review.

## Guidelines

Try to answer the following questions in your first section:

1. Why would I want to read this document?

2. What should I know to be able to follow along with this document?

3. What will I have learned by the end of this document?

Common names for the first section are `Introduction`, `Overview`, or
`Background`.

If possible, make your document a "how to". Give it a name `HowTo*.md`
like the other "how to" documents. This format is usually the easiest
for another person to understand and also the most useful.

You generally should not be writing documentation other than a "how to"
unless there is already a "how to" about your topic. The reason for this
is that without a "how to" document to read first, it is difficult for a
person to understand a more advanced document.

Focus on content (yes, I had to say it again).

The rest of this document shows example Markdown markup constructs
that are meant to be read by you in your text editor after you have copied
this file into a new file for the documentation you are about to write.

## Example Section

Your text can be *emphasized*, **bold**, or `monospace`.

Use blank lines to separate paragraphs.

Headings (like `Example Section` just above) give your document its
structure.

### Example Subsection

Make a link [like this](http://llvm.org/). There is also a more
sophisticated syntax which [can be more readable] for longer links since
it disrupts the flow less. You can put the `[link name]: <URL>` block
pretty much anywhere later in the document.

[can be more readable]: http://en.wikipedia.org/wiki/LLVM

Lists can be made like this:

1. A list starting with `[0-9].` will be automatically numbered.

1. This is a second list element.

   1. Use indentation to create nested lists.

You can also use unordered lists.

* Stuff.

  + Deeper stuff.

* More stuff.

#### Example Subsubsection

You can make blocks of code like this:

```
int main() {
  return 0;
}
```

As an extension to markdown, you can also specify a highlighter to use.

``` C++
int main() {
  return 0;
}
```

For a shell session, use a `console` code block.

```console
$ echo "Goodbye cruel world!"
$ rm -rf /
```

If you need to show LLVM IR use the `llvm` code block.

``` llvm
define i32 @test1() {
entry:
  ret i32 0
}
```

Some other common code blocks you might need are `c`, `objc`, `make`,
and `cmake`. If you need something beyond that, you can look at the [full
list] of supported code blocks.

[full list]: http://pygments.org/docs/lexers/

However, don't waste time fiddling with syntax highlighting when you could
be adding meaningful content. When in doubt, show preformatted text
without any syntax highlighting like this:

                          .
                           +:.
                       ..:: ::
                    .++:+:: ::+:.:.
                   .:+           :
            ::.::..::            .+.
          ..:+    ::              :
    ......+:.                    ..
          :++.    ..              :
            .+:::+::              :
            ..   . .+            ::
                     +.:      .::+.
                      ...+. .: .
                         .++:..
                          ...

##### Hopefully you won't need to be this deep

If you need to do fancier things than what has been shown in this document,
you can mail the list or check the [Common Mark spec].  Sphinx specific
integration documentation can be found in the [recommonmark docs].

[Common Mark spec]: http://spec.commonmark.org/0.28/
[recommonmark docs]: http://recommonmark.readthedocs.io/en/latest/index.html