From: Eric Christopher Date: Thu, 10 Dec 2015 22:04:11 +0000 (+0000) Subject: Attempt to fix the ReST compilation to html of the C API docs. X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=67b9896fe1fe5313de3a728d01a94fa2486e07ea;p=oota-llvm.git Attempt to fix the ReST compilation to html of the C API docs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255304 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/DeveloperPolicy.rst b/docs/DeveloperPolicy.rst index 47c3b8b3d29..d4a681a8b31 100644 --- a/docs/DeveloperPolicy.rst +++ b/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: