doc/dev/crimson: highlight code blocks using C++ lexer

also remove redundant ":", normally "::" would suffice to start a
codeblock.

Signed-off-by: Kefu Chai <kchai@redhat.com>

diff --git a/doc/dev/crimson/error-handling.rst b/doc/dev/crimson/error-handling.rst
index 6caaea3e7e9a1ed31d51fe01b464f1a743141e30..ee241d95891448da574347352b20df7bba2c9584 100644 (file)
--- a/doc/dev/crimson/error-handling.rst
+++ b/doc/dev/crimson/error-handling.rst
@@ -36,12 +36,12 @@ Unfortunately, `seastar::future` is not able to satisfy these two requirements.
   mental load on programmers as ensuring that all intended errors are indeed handled
   requires manual code audit.
 
+.. highlight:: c++
+
 So, "errorator" is created. It is a wrapper around the vanilla `seastar::future`.
 It addresses the performance and scalability issues while embedding the information
 about all expected types-of-errors to the type-of-future.::
 
-
-
   using ertr = crimson::errorator<crimson::ct_error::enoent,
                                   crimson::ct_error::einval>;
 
@@ -55,7 +55,7 @@ unthrowable wrappers over `std::error_code` to exclude accidental throwing
 and ensure signaling errors in a way that enables compile-time checking.
 
 The most fundamental thing in an errorator is a descendant of `seastar::future`
-which can be used as e.g. function's return type:::
+which can be used as e.g. function's return type::
 
   static ertr::future<int> foo(int bar) {
     if (bar == 42) {
@@ -66,7 +66,7 @@ which can be used as e.g. function's return type:::
   }
 
 It's worth to note that returning an error that is not a part the errorator's error set
-would result in a compile-time error:::
+would result in a compile-time error::
 
   static ertr::future<int> foo(int bar) {
     // Oops, input_output_error is not allowed in `ertr`.  static_assert() will
@@ -82,7 +82,7 @@ about all potential errors embedded in the function's type; it also ensures at t
 site that all these errors are handled. As the reader probably know, the main method
 in `seastar::future` is `then()`. On errorated future it is available but only if errorator's
 error set is empty (literally: `errorator<>::future`); otherwise callers have
-to use `safe_then()` instead:::
+to use `safe_then()` instead::
 
   seastar::future<> baz() {
     return foo(42).safe_then(
@@ -131,7 +131,7 @@ of `then()`::
 That is, handling errors removes them from errorated future's error set. This works
 in the opposite direction too -- returning new errors in `safe_then()` appends them
 the error set. Of course, this set must be compliant with error set in the `baz()`'s
-signature:::
+signature::
 
   using broader_ertr = crimson::errorator<crimson::ct_error::enoent,
                                           crimson::ct_error::einval,