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>
This commit is contained in:
Kefu Chai 2020-12-15 17:40:59 +08:00
parent 6828213a11
commit 370f04fa82

View File

@ -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,