diff options
| author | Eric Christopher <echristo@gmail.com> | 2015-12-10 22:04:11 +0000 |
|---|---|---|
| committer | Eric Christopher <echristo@gmail.com> | 2015-12-10 22:04:11 +0000 |
| commit | 2ec6a49fbf4be2931eddce3aff3c6594cec4d76f (patch) | |
| tree | 7d85980922bcea9c1c01b5f972f2c99d9f58c680 | |
| parent | df2e4d2914098e7fa5eef500aa9894d042f1a39d (diff) | |
| download | bcm5719-llvm-2ec6a49fbf4be2931eddce3aff3c6594cec4d76f.tar.gz bcm5719-llvm-2ec6a49fbf4be2931eddce3aff3c6594cec4d76f.zip | |
Attempt to fix the ReST compilation to html of the C API docs.
llvm-svn: 255304
| -rw-r--r-- | llvm/docs/DeveloperPolicy.rst | 28 |
1 files changed, 14 insertions, 14 deletions
diff --git a/llvm/docs/DeveloperPolicy.rst b/llvm/docs/DeveloperPolicy.rst index 47c3b8b3d29..d4a681a8b31 100644 --- a/llvm/docs/DeveloperPolicy.rst +++ b/llvm/docs/DeveloperPolicy.rst @@ -529,28 +529,28 @@ C API Changes ---------------- * Stability Guarantees: The C API is, in general, a "best effort" for stability. -This means that we make every attempt to keep the C API stable, but that -stability will be limited by the abstractness of the interface and the stability -of the C++ API that it wraps. In practice, this means that things like "create -debug info" or "create this type of instruction" are likely to be less stable -than "take this IR file and JIT it for my current machine". + This means that we make every attempt to keep the C API stable, but that + stability will be limited by the abstractness of the interface and the + stability of the C++ API that it wraps. In practice, this means that things + like "create debug info" or "create this type of instruction" are likely to be + less stable than "take this IR file and JIT it for my current machine". * Release stability: We won't break the C API on the release branch with patches -that go on that branch, with the exception that if we will fix an unintentional -C API break that will keep the release consistent with both the previous and next -release. + that go on that branch, with the exception that if we will fix an unintentional + C API break that will keep the release consistent with both the previous and + next release. * Testing: Patches to the C API are expected to come with tests just like any -other patch. + other patch. * Including new things into the API: If an LLVM subcomponent has a C API already -included, then expanding that C API is acceptable. Adding C API for subcomponents -that don't currently have one need to be discussed on the mailing list for design -and maintainability feedback prior to implementation. + included, then expanding that C API is acceptable. Adding C API for + subcomponents that don't currently have one need to be discussed on the mailing + list for design and maintainability feedback prior to implementation. * Documentation: Any changes to the C API are required to be documented in the -release notes so that it's clear to external users who do not follow the project -how the C API is changing and evolving. + release notes so that it's clear to external users who do not follow the + project how the C API is changing and evolving. .. _copyright-license-patents: |
