Skip to content

[docs] Fix syntax highlighting issues to support newer Sphinxes. #4283

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 13, 2016
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions docs/ABI.rst
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,8 @@
.. @raise litre.TestsAreMissing
.. _ABI:

.. highlight:: none

The Swift ABI
=============

Expand Down
2 changes: 2 additions & 0 deletions docs/ARCOptimization.rst
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
:orphan:

.. highlight:: sil

==========================
ARC Optimization for Swift
==========================
Expand Down
2 changes: 2 additions & 0 deletions docs/DebuggingTheCompiler.rst
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
:orphan:

.. highlight:: none

Debugging the Swift Compiler
============================

Expand Down
2 changes: 2 additions & 0 deletions docs/DriverParseableOutput.rst
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@ Parseable Driver Output
.. contents::
:local:

.. highlight:: none

Introduction
============

Expand Down
10 changes: 7 additions & 3 deletions docs/ErrorHandlingRationale.rst
Original file line number Diff line number Diff line change
Expand Up @@ -879,15 +879,19 @@ generally needs as much code in the function as implicit manual
propagation would. However, we could optimize this for many common
cases by causing clean-ups to be called automatically by the
interpretation function. That is, instead of a landing pad that looks
notionally like this::
notionally like this:

void *exception = ...;
.. code-block:: objc++

void *exception = /*...*/;
SomeCXXType::~SomeCXXType(&foo);
objc_release(bar);
objc_release(baz);
_Unwind_Resume(exception);

The unwind table would have a record that looks notionally like this::
The unwind table would have a record that looks notionally like this:

.. code-block:: objc++

CALL_WITH_FRAME_ADDRESS(&SomeCXXType::~SomeCXXType, FRAME_OFFSET_OF(foo))
CALL_WITH_FRAME_VALUE(&objc_release, FRAME_OFFSET_OF(bar))
Expand Down
2 changes: 2 additions & 0 deletions docs/GitWorkflows.rst
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
:orphan:

.. highlight:: bash

Git Workflows
=============

Expand Down
10 changes: 5 additions & 5 deletions docs/LibraryEvolution.rst
Original file line number Diff line number Diff line change
Expand Up @@ -121,7 +121,7 @@ specifying the name of the client library along with the required version::

// Client code
@available(Magician 1.5)
class CrystalBallView : MagicView { }
class CrystalBallView : MagicView { /*…*/ }

Library versions can also be checked dynamically using ``#available``, allowing
for fallback behavior when the requested library version is not present::
Expand Down Expand Up @@ -351,7 +351,7 @@ example using methods::

public struct Point2D {
var x, y: Double
public init(x: Double, y: Double) { }
public init(x: Double, y: Double) { /*…*/ }
}

extension Point2D {
Expand All @@ -368,7 +368,7 @@ polar representation::

public struct Point2D {
var r, theta: Double
public init(x: Double, y: Double) { }
public init(x: Double, y: Double) { /*…*/ }
}

and the ``x`` and ``y`` properties have now disappeared. To avoid this, the
Expand Down Expand Up @@ -693,13 +693,13 @@ can enforce its safe use.
We've considered two possible syntaxes for this::

@available(1.1)
extension Wand : MagicType {}
extension Wand : MagicType {/*…*/}

and

::

extension Wand : @available(1.1) MagicType {}
extension Wand : @available(1.1) MagicType {/*…*/}

The former requires fewer changes to the language grammar, but the latter could
also be used on the declaration of the type itself (i.e. the ``struct``
Expand Down
2 changes: 1 addition & 1 deletion docs/MutationModel.rst
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ What do we do with this? Since ``+=`` has an ``inout`` first
argument, we detect this situation statically (hopefully one day we'll
have a better error message):

::
.. code-block:: swift-console

<REPL Input>:1:9: error: expression does not type-check
w.title += " (parenthesized remark)"
Expand Down
8 changes: 4 additions & 4 deletions docs/PatternMatching.rst
Original file line number Diff line number Diff line change
Expand Up @@ -292,20 +292,20 @@ braces end up causing a lot of unnecessary vertical whitespace, like so::

switch (x)
case .foo {
//
}
case .bar {
//
}

So instead, let's require the switch statement to have braces, and
we'll allow the cases to be written without them::

switch (x) {
case .foo:
//
case .bar:
//
}

That's really a lot prettier, except it breaks the rule about always grouping
Expand Down
1 change: 1 addition & 0 deletions docs/SIL.rst
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
.. @raise litre.TestsAreMissing
.. highlight:: none

Swift Intermediate Language (SIL)
=================================
Expand Down
4 changes: 3 additions & 1 deletion docs/StringDesign.rst
Original file line number Diff line number Diff line change
Expand Up @@ -389,7 +389,9 @@ end, strings support properties for more-specific segmentations:
`Search Grapheme Cluster: o`

Also, each such segmentation provides a unique ``IndexType``, allowing
a string to be indexed directly with different indexing schemes::
a string to be indexed directly with different indexing schemes

.. code-block:: swift-console

|swift| var i = s.searchCharacters.startIndex
`// r2 : UInt8 = UInt8(83)`
Expand Down
10 changes: 7 additions & 3 deletions docs/Testing.rst
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,9 @@ test suite, via ``utils/build-script --validation-test``.
Although it is not recommended for day-to-day contributions, it is also
technically possible to execute the tests directly via CMake. For example, if you have
built Swift products at the directory ``build/Ninja-ReleaseAssert/swift-macosx-x86_64``,
you may run the entire test suite directly using the following command::
you may run the entire test suite directly using the following command:

.. code-block:: bash

cmake --build build/Ninja-ReleaseAssert/swift-macosx-x86_64 -- check-swift-macosx-x86_64

Expand Down Expand Up @@ -112,7 +114,9 @@ For every target above, there are variants for different optimizations:
``executable_test`` in ``-Onone`` mode.

If you need to manually run certain tests, you can invoke LLVM's lit.py script
directly. For example::
directly. For example:

.. code-block:: bash

% ${LLVM_SOURCE_ROOT}/utils/lit/lit.py -sv ${SWIFT_BUILD_ROOT}/test-iphonesimulator-i386/Parse/

Expand All @@ -128,7 +132,7 @@ source 'test/' directory.) There is a more verbose form that specifies the
testing configuration explicitly, which then allows you to test files
regardless of location.

::
.. code-block:: bash

% ${LLVM_SOURCE_ROOT}/utils/lit/lit.py -sv --param swift_site_config=${SWIFT_BUILD_ROOT}/test-iphonesimulator-i386/lit.site.cfg ${SWIFT_SOURCE_ROOT}/test/Parse/

Expand Down
2 changes: 1 addition & 1 deletion docs/archive/LangRefNew.rst
Original file line number Diff line number Diff line change
Expand Up @@ -494,7 +494,7 @@ The Swift compiler does not normalize Unicode source code, and matches
identifiers by code points only. Source code must be normalized to a consistent
normalization form before being submitted to the compiler.

::
.. code-block:: none

// Valid identifiers
foo
Expand Down
2 changes: 2 additions & 0 deletions docs/conf.py
Original file line number Diff line number Diff line change
Expand Up @@ -287,6 +287,8 @@
def swift_get_lexer_by_name(_alias, *args, **kw):
if _alias == 'swift':
return swift_pygments_lexers.SwiftLexer()
elif _alias == 'sil':
return swift_pygments_lexers.SILLexer()
elif _alias == 'swift-console':
return swift_pygments_lexers.SwiftConsoleLexer()
else:
Expand Down
8 changes: 6 additions & 2 deletions docs/proposals/Concurrency.rst
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,9 @@ deallocated class instance. To understand the bug try to imagine two threads
executing the SIL code below in lockstep. After they both load the same value
they both try to release the object. One thread succeeds and deallocates the
object while another thread attempts to read the memory of a deallocated
object::
object:

.. code-block:: sil

%10 = global_addr @singleton : $*Bird

Expand All @@ -78,7 +80,9 @@ object::

Next, we'll look into the problem of sliced values. Intuitively, it is easy to
see why sharing memory between two threads could lead to catastrophic bugs.
Consider the program below::
Consider the program below:

.. code-block:: none

Thread #1: Thread #2:
A.first = "John" A.first = "Paul"
Expand Down
2 changes: 2 additions & 0 deletions docs/proposals/InoutCOWOptimization.rst
Original file line number Diff line number Diff line change
@@ -1,4 +1,6 @@
:orphan:

.. highlight:: sil

================================================
Copy-On-Write Optimization of ``inout`` Values
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,6 +3,8 @@
.. @raise litre.TestsAreMissing
.. _ProgramStructureAndCompilationModel:

.. highlight:: none

Swift Program Structure and Compilation Model
=============================================

Expand Down
Loading