3 ### Single line formatting
6 * `[T; expr]`, e.g., `[u32; 42]`, `[Vec<Foo>; 10 * 2 + foo()]` (space after colon, no spaces around square brackets)
7 * `*const T`, `*mut T` (no space after `*`, space before type)
8 * `&'a T`, `&T`, `&'a mut T`, `&mut T` (no space after `&`, single spaces separating other words)
9 * `unsafe extern "C" fn<'a, 'b, 'c>(T, U, V) -> W` or `fn()` (single spaces around keyowrds and sigils, and after commas, no trailing commas, no spaces around brackets)
10 * `!` should be treated like any other type name, `Name`
11 * `(A, B, C, D)` (spaces after commas, no spaces around parens, no trailing comma unless it is a one-tuple)
12 * `<Baz<T> as SomeTrait>::Foo::Bar` or `Foo::Bar` or `::Foo::Bar` (no spaces around `::` or angle brackets, single spaces around `as`)
13 * `Foo::Bar<T, U, V>` (spaces after commas, no trailing comma, no spaces around angle brackets)
14 * `T + T + T` (single spaces between types, and `+`).
15 * `impl T + T + T` (single spaces between keyword, types, and `+`).
17 Parentheses used in types should not be surrounded by whitespace, e.g., `(Foo)`
22 Avoid breaking lines in types where possible. Prefer breaking at outermost scope, e.g., prefer
40 `[T; expr]` may be broken after the `;` if necessary.
42 Function types may be broken following the rules for function declarations.
44 Generic types may be broken following the rules for generics.
46 Types with `+` may be broken after any `+` using block indent and breaking before the `+`. When breaking such a type, all `+`s should be line broken, e.g.,