There is a range of different wordings used in the docs of constructor
type functions.
Change all to start with `Constructs a new` or `Constructs an empty`.
In functions that act like constructors there is a mixture of the usage
of `creates` and `constructs`.
Replace all occurrences of `creates` with `constructs` in the first line
of docs of constructor like functions.
In #2521 I removed the link from `std::error::Error` with the claim that
it broke no-std builds. However there are a ton of other places where we
link to `std::` types.
I have no idea where the breakage was, I assume it existed and I was
sane at the time, CI on this patch will tell us.
Close: #2571
In a few cases a function header documents the parameters of the following function under the heading"Arguments", this has been changed to "Parameters"
We can't link to `std::error::Error` in rustdoc because it breaks
non-std builds. Just use backticks - this is not an optimal solution but
I know no other.
I have no clue why this is showing up now.
We would like the codebase to be optimized for readability not ease of
development, as such code that is write-once-read-many should not use
macros.
Currently we use the `impl_std_error` macro to implement
`std::error::Error` for struct error types. This makes the code harder
to read at a glance because one has to think what the macro does.
Remove the `impl_std_error` macro and write the code explicitly.
This implements basic facilities to conditionally carry string inputs in
parse errors. This includes:
* `InputString` type that may carry the input and format it
* `parse_error_type!` macro creating a special type for parse errors
* `impl_parse` implementing parsing for various types as well as its
`serde`-supporting alternative
Jamil Lambert, PhD
Tobin C. Harding
Martin Habovstiak