Differences spotted in "Utilities for formatting and printing `String`s\n\nThis module contains the runtime support for the [`format!`] syntax extension.\nThis macro is implemented in the compiler to emit calls to this module in\norder to format arguments at runtime into strings.\n\n# Usage\n\nThe [`format!`] macro is intended to be familiar to those coming from C\'s\n`printf`/`fprintf` functions or Python\'s `str.format` function.\n\nSome examples of the [`format!`] extension are:\n\n```\nformat!(\"Hello\");                 // => \"Hello\"\nformat!(\"Hello, {}!\", \"world\");   // => \"Hello, world!\"\nformat!(\"The number is {}\", 1);   // => \"The number is 1\"\nformat!(\"{:?}\", (3, 4));          // => \"(3, 4)\"\nformat!(\"{value}\", value=4);      // => \"4\"\nformat!(\"{} {}\", 1, 2);           // => \"1 2\"\nformat!(\"{:04}\", 42);             // => \"0042\" with leading zeros\n```\n\nFrom these, you can see that the first argument is a format string. It is\nrequired by the compiler for this to be a string literal; it cannot be a\nvariable passed in (in order to perform validity checking). The compiler\nwill then parse the format string and determine if the list of arguments\nprovided is suitable to pass to this format string.\n\n## Positional parameters\n\nEach formatting argument is allowed to specify which value argument it\'s\nreferencing, and if omitted it is assumed to be \"the next argument\". For\nexample, the format string `{} {} {}` would take three parameters, and they\nwould be formatted in the same order as they\'re given. The format string\n`{2} {1} {0}`, however, would format arguments in reverse order.\n\nThings can get a little tricky once you start intermingling the two types of\npositional specifiers. The \"next argument\" specifier can be thought of as an\niterator over the argument. Each time a \"next argument\" specifier is seen,\nthe iterator advances. This leads to behavior like this:\n\n```\nformat!(\"{1} {} {0} {}\", 1, 2); // => \"2 1 1 2\"\n```\n\nThe internal iterator over the argument has not been advanced by the time\nthe first `{}` is seen, so it prints the first argument. Then upon reaching\nthe second `{}`, the iterator has advanced forward to the second argument.\nEssentially, parameters which explicitly name their argument do not affect\nparameters which do not name an argument in terms of positional specifiers.\n\nA format string is required to use all of its arguments, otherwise it is a\ncompile-time error. You may refer to the same argument more than once in the\nformat string.\n\n## Named parameters\n\nRust itself does not have a Python-like equivalent of named parameters to a\nfunction, but the [`format!`] macro is a syntax extension which allows it to\nleverage named parameters. Named parameters are listed at the end of the\nargument list and have the syntax:\n\n```text\nidentifier \'=\' expression\n```\n\nFor example, the following [`format!`] expressions all use named argument:\n\n```\nformat!(\"{argument}\", argument = \"test\");   // => \"test\"\nformat!(\"{name} {}\", 1, name = 2);          // => \"2 1\"\nformat!(\"{a} {c} {b}\", a=\"a\", b=\'b\', c=3);  // => \"a 3 b\"\n```\n\nIt is not valid to put positional parameters (those without names) after\narguments which have names. Like with positional parameters, it is not\nvalid to provide named parameters that are unused by the format string.\n\n## Argument types\n\nEach argument\'s type is dictated by the format string.\nThere are various parameters which require a particular type, however.\nAn example is the `{:.*}` syntax, which sets the number of decimal places\nin floating-point types:\n\n```\nlet formatted_number = format!(\"{:.*}\", 2, 1.234567);\n\nassert_eq!(\"1.23\", formatted_number)\n```\n\nIf this syntax is used, then the number of characters to print precedes the\nactual object being formatted, and the number of characters must have the\ntype [`usize`].\n\n## Formatting traits\n\nWhen requesting that an argument be formatted with a particular type, you\nare actually requesting that an argument ascribes to a particular trait.\nThis allows multiple actual types to be formatted via `{:x}` (like [`i8`] as\nwell as [`isize`]).  The current mapping of types to traits is:\n\n* *nothing* ⇒ [`Display`]\n* `?` ⇒ [`Debug`]\n* `o` ⇒ [`Octal`](trait.Octal.html)\n* `x` ⇒ [`LowerHex`](trait.LowerHex.html)\n* `X` ⇒ [`UpperHex`](trait.UpperHex.html)\n* `p` ⇒ [`Pointer`](trait.Pointer.html)\n* `b` ⇒ [`Binary`]\n* `e` ⇒ [`LowerExp`](trait.LowerExp.html)\n* `E` ⇒ [`UpperExp`](trait.UpperExp.html)\n\nWhat this means is that any type of argument which implements the\n[`fmt::Binary`][`Binary`] trait can then be formatted with `{:b}`. Implementations\nare provided for these traits for a number of primitive types by the\nstandard library as well. If no format is specified (as in `{}` or `{:6}`),\nthen the format trait used is the [`Display`] trait.\n\nWhen implementing a format trait for your own type, you will have to\nimplement a method of the signature:\n\n```\n# #![allow(dead_code)]\n# use std::fmt;\n# struct Foo; // our custom type\n# impl fmt::Display for Foo {\nfn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n# write!(f, \"testing, testing\")\n# } }\n```\n\nYour type will be passed as `self` by-reference, and then the function\nshould emit output into the `f.buf` stream. It is up to each format trait\nimplementation to correctly adhere to the requested formatting parameters.\nThe values of these parameters will be listed in the fields of the\n[`Formatter`] struct. In order to help with this, the [`Formatter`] struct also\nprovides some helper methods.\n\nAdditionally, the return value of this function is [`fmt::Result`] which is a\ntype alias of [`Result`]`<(), `[`std::fmt::Error`]`>`. Formatting implementations\nshould ensure that they propagate errors from the [`Formatter`][`Formatter`] (e.g., when\ncalling [`write!`]) however, they should never return errors spuriously. That\nis, a formatting implementation must and may only return an error if the\npassed-in [`Formatter`] returns an error. This is because, contrary to what\nthe function signature might suggest, string formatting is an infallible\noperation. This function only returns a result because writing to the\nunderlying stream might fail and it must provide a way to propagate the fact\nthat an error has occurred back up the stack.\n\nAn example of implementing the formatting traits would look\nlike:\n\n```\nuse std::fmt;\n\n#[derive(Debug)]\nstruct Vector2D {\n    x: isize,\n    y: isize,\n}\n\nimpl fmt::Display for Vector2D {\n    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n        // The `f` value implements the `Write` trait, which is what the\n        // write! macro is expecting. Note that this formatting ignores the\n        // various flags provided to format strings.\n        write!(f, \"({}, {})\", self.x, self.y)\n    }\n}\n\n// Different traits allow different forms of output of a type. The meaning\n// of this format is to print the magnitude of a vector.\nimpl fmt::Binary for Vector2D {\n    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n        let magnitude = (self.x * self.x + self.y * self.y) as f64;\n        let magnitude = magnitude.sqrt();\n\n        // Respect the formatting flags by using the helper method\n        // `pad_integral` on the Formatter object. See the method\n        // documentation for details, and the function `pad` can be used\n        // to pad strings.\n        let decimals = f.precision().unwrap_or(3);\n        let string = format!(\"{:.*}\", decimals, magnitude);\n        f.pad_integral(true, \"\", &string)\n    }\n}\n\nfn main() {\n    let myvector = Vector2D { x: 3, y: 4 };\n\n    println!(\"{}\", myvector);       // => \"(3, 4)\"\n    println!(\"{:?}\", myvector);     // => \"Vector2D {x: 3, y:4}\"\n    println!(\"{:10.3b}\", myvector); // => \"     5.000\"\n}\n```\n\n### `fmt::Display` vs `fmt::Debug`\n\nThese two formatting traits have distinct purposes:\n\n- [`fmt::Display`][`Display`] implementations assert that the type can be faithfully\n  represented as a UTF-8 string at all times. It is **not** expected that\n  all types implement the [`Display`] trait.\n- [`fmt::Debug`][`Debug`] implementations should be implemented for **all** public types.\n  Output will typically represent the internal state as faithfully as possible.\n  The purpose of the [`Debug`] trait is to facilitate debugging Rust code. In\n  most cases, using `#[derive(Debug)]` is sufficient and recommended.\n\nSome examples of the output from both traits:\n\n```\nassert_eq!(format!(\"{} {:?}\", 3, 4), \"3 4\");\nassert_eq!(format!(\"{} {:?}\", \'a\', \'b\'), \"a \'b\'\");\nassert_eq!(format!(\"{} {:?}\", \"foo\\n\", \"bar\\n\"), \"foo\\n \\\"bar\\\\n\\\"\");\n```\n\n## Related macros\n\nThere are a number of related macros in the [`format!`] family. The ones that\nare currently implemented are:\n\n```ignore (only-for-syntax-highlight)\nformat!      // described above\nwrite!       // first argument is a &mut io::Write, the destination\nwriteln!     // same as write but appends a newline\nprint!       // the format string is printed to the standard output\nprintln!     // same as print but appends a newline\nformat_args! // described below.\n```\n\n### `write!`\n\nThis and [`writeln!`] are two macros which are used to emit the format string\nto a specified stream. This is used to prevent intermediate allocations of\nformat strings and instead directly write the output. Under the hood, this\nfunction is actually invoking the [`write_fmt`] function defined on the\n[`std::io::Write`] trait. Example usage is:\n\n```\n# #![allow(unused_must_use)]\nuse std::io::Write;\nlet mut w = Vec::new();\nwrite!(&mut w, \"Hello {}!\", \"world\");\n```\n\n### `print!`\n\nThis and [`println!`] emit their output to stdout. Similarly to the [`write!`]\nmacro, the goal of these macros is to avoid intermediate allocations when\nprinting output. Example usage is:\n\n```\nprint!(\"Hello {}!\", \"world\");\nprintln!(\"I have a newline {}\", \"character at the end\");\n```\n\n### `format_args!`\n\nThis is a curious macro which is used to safely pass around\nan opaque object describing the format string. This object\ndoes not require any heap allocations to create, and it only\nreferences information on the stack. Under the hood, all of\nthe related macros are implemented in terms of this. First\noff, some example usage is:\n\n```\n# #![allow(unused_must_use)]\nuse std::fmt;\nuse std::io::{self, Write};\n\nlet mut some_writer = io::stdout();\nwrite!(&mut some_writer, \"{}\", format_args!(\"print with a {}\", \"macro\"));\n\nfn my_fmt_fn(args: fmt::Arguments) {\n    write!(&mut io::stdout(), \"{}\", args);\n}\nmy_fmt_fn(format_args!(\", or a {} too\", \"function\"));\n```\n\nThe result of the [`format_args!`] macro is a value of type [`fmt::Arguments`].\nThis structure can then be passed to the [`write`] and [`format`] functions\ninside this module in order to process the format string.\nThe goal of this macro is to even further prevent intermediate allocations\nwhen dealing formatting strings.\n\nFor example, a logging library could use the standard formatting syntax, but\nit would internally pass around this structure until it has been determined\nwhere output should go to.\n\n# Syntax\n\nThe syntax for the formatting language used is drawn from other languages,\nso it should not be too alien. Arguments are formatted with Python-like\nsyntax, meaning that arguments are surrounded by `{}` instead of the C-like\n`%`. The actual grammar for the formatting syntax is:\n\n```text\nformat_string := <text> [ maybe-format <text> ] *\nmaybe-format := \'{\' \'{\' | \'}\' \'}\' | <format>\nformat := \'{\' [ argument ] [ \':\' format_spec ] \'}\'\nargument := integer | identifier\n\nformat_spec := [[fill]align][sign][\'#\'][\'0\'][width][\'.\' precision][type]\nfill := character\nalign := \'<\' | \'^\' | \'>\'\nsign := \'+\' | \'-\'\nwidth := count\nprecision := count | \'*\'\ntype := identifier | \'\'\ncount := parameter | integer\nparameter := argument \'$\'\n```\n\n# Formatting Parameters\n\nEach argument being formatted can be transformed by a number of formatting\nparameters (corresponding to `format_spec` in the syntax above). These\nparameters affect the string representation of what\'s being formatted. This\nsyntax draws heavily from Python\'s, so it may seem a bit familiar.\n\n## Fill/Alignment\n\nThe fill character is provided normally in conjunction with the `width`\nparameter. This indicates that if the value being formatted is smaller than\n`width` some extra characters will be printed around it. The extra\ncharacters are specified by `fill`, and the alignment can be one of the\nfollowing options:\n\n* `<` - the argument is left-aligned in `width` columns\n* `^` - the argument is center-aligned in `width` columns\n* `>` - the argument is right-aligned in `width` columns\n\nNote that alignment may not be implemented by some types. A good way\nto ensure padding is applied is to format your input, then use this\nresulting string to pad your output.\n\n## Sign/`#`/`0`\n\nThese can all be interpreted as flags for a particular formatter.\n\n* `+` - This is intended for numeric types and indicates that the sign\n        should always be printed. Positive signs are never printed by\n        default, and the negative sign is only printed by default for the\n        `Signed` trait. This flag indicates that the correct sign (`+` or `-`)\n        should always be printed.\n* `-` - Currently not used\n* `#` - This flag is indicates that the \"alternate\" form of printing should\n        be used. The alternate forms are:\n    * `#?` - pretty-print the [`Debug`] formatting\n    * `#x` - precedes the argument with a `0x`\n    * `#X` - precedes the argument with a `0x`\n    * `#b` - precedes the argument with a `0b`\n    * `#o` - precedes the argument with a `0o`\n* `0` - This is used to indicate for integer formats that the padding should\n        both be done with a `0` character as well as be sign-aware. A format\n        like `{:08}` would yield `00000001` for the integer `1`, while the\n        same format would yield `-0000001` for the integer `-1`. Notice that\n        the negative version has one fewer zero than the positive version.\n        Note that padding zeroes are always placed after the sign (if any)\n        and before the digits. When used together with the `#` flag, a similar\n        rule applies: padding zeroes are inserted after the prefix but before\n        the digits.\n\n## Width\n\nThis is a parameter for the \"minimum width\" that the format should take up.\nIf the value\'s string does not fill up this many characters, then the\npadding specified by fill/alignment will be used to take up the required\nspace.\n\nThe default fill/alignment for non-numerics is a space and left-aligned. The\ndefaults for numeric formatters is also a space but with right-alignment. If\nthe `0` flag is specified for numerics, then the implicit fill character is\n`0`.\n\nThe value for the width can also be provided as a [`usize`] in the list of\nparameters by using the dollar syntax indicating that the second argument is\na [`usize`] specifying the width, for example:\n\n```\n// All of these print \"Hello x    !\"\nprintln!(\"Hello {:5}!\", \"x\");\nprintln!(\"Hello {:1$}!\", \"x\", 5);\nprintln!(\"Hello {1:0$}!\", 5, \"x\");\nprintln!(\"Hello {:width$}!\", \"x\", width = 5);\n```\n\nReferring to an argument with the dollar syntax does not affect the \"next\nargument\" counter, so it\'s usually a good idea to refer to arguments by\nposition, or use named arguments.\n\n## Precision\n\nFor non-numeric types, this can be considered a \"maximum width\". If the resulting string is\nlonger than this width, then it is truncated down to this many characters and that truncated\nvalue is emitted with proper `fill`, `alignment` and `width` if those parameters are set.\n\nFor integral types, this is ignored.\n\nFor floating-point types, this indicates how many digits after the decimal point should be\nprinted.\n\nThere are three possible ways to specify the desired `precision`:\n\n1. An integer `.N`:\n\n   the integer `N` itself is the precision.\n\n2. An integer or name followed by dollar sign `.N$`:\n\n   use format *argument* `N` (which must be a `usize`) as the precision.\n\n3. An asterisk `.*`:\n\n   `.*` means that this `{...}` is associated with *two* format inputs rather than one: the\n   first input holds the `usize` precision, and the second holds the value to print.  Note that\n   in this case, if one uses the format string `{<arg>:<spec>.*}`, then the `<arg>` part refers\n   to the *value* to print, and the `precision` must come in the input preceding `<arg>`.\n\nFor example, the following calls all print the same thing `Hello x is 0.01000`:\n\n```\n// Hello {arg 0 (\"x\")} is {arg 1 (0.01) with precision specified inline (5)}\nprintln!(\"Hello {0} is {1:.5}\", \"x\", 0.01);\n\n// Hello {arg 1 (\"x\")} is {arg 2 (0.01) with precision specified in arg 0 (5)}\nprintln!(\"Hello {1} is {2:.0$}\", 5, \"x\", 0.01);\n\n// Hello {arg 0 (\"x\")} is {arg 2 (0.01) with precision specified in arg 1 (5)}\nprintln!(\"Hello {0} is {2:.1$}\", \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {second of next two args (0.01) with precision\n//                          specified in first of next two args (5)}\nprintln!(\"Hello {} is {:.*}\",    \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {arg 2 (0.01) with precision\n//                          specified in its predecessor (5)}\nprintln!(\"Hello {} is {2:.*}\",   \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {arg \"number\" (0.01) with precision specified\n//                          in arg \"prec\" (5)}\nprintln!(\"Hello {} is {number:.prec$}\", \"x\", prec = 5, number = 0.01);\n```\n\nWhile these:\n\n```\nprintln!(\"{}, `{name:.*}` has 3 fractional digits\", \"Hello\", 3, name=1234.56);\nprintln!(\"{}, `{name:.*}` has 3 characters\", \"Hello\", 3, name=\"1234.56\");\nprintln!(\"{}, `{name:>8.*}` has 3 right-aligned characters\", \"Hello\", 3, name=\"1234.56\");\n```\n\nprint two significantly different things:\n\n```text\nHello, `1234.560` has 3 fractional digits\nHello, `123` has 3 characters\nHello, `     123` has 3 right-aligned characters\n```\n\n# Escaping\n\nThe literal characters `{` and `}` may be included in a string by preceding\nthem with the same character. For example, the `{` character is escaped with\n`{{` and the `}` character is escaped with `}}`.\n\n[`format!`]: ../../macro.format.html\n[`usize`]: ../../std/primitive.usize.html\n[`isize`]: ../../std/primitive.isize.html\n[`i8`]: ../../std/primitive.i8.html\n[`Display`]: trait.Display.html\n[`Binary`]: trait.Binary.html\n[`fmt::Result`]: type.Result.html\n[`Result`]: ../../std/result/enum.Result.html\n[`std::fmt::Error`]: struct.Error.html\n[`Formatter`]: struct.Formatter.html\n[`write!`]: ../../std/macro.write.html\n[`Debug`]: trait.Debug.html\n[`format!`]: ../../std/macro.format.html\n[`writeln!`]: ../../std/macro.writeln.html\n[`write_fmt`]: ../../std/io/trait.Write.html#method.write_fmt\n[`std::io::Write`]: ../../std/io/trait.Write.html\n[`println!`]: ../../std/macro.println.html\n[`write!`]: ../../std/macro.write.html\n[`format_args!`]: ../../std/macro.format_args.html\n[`fmt::Arguments`]: struct.Arguments.html\n[`write`]: fn.write.html\n[`format`]: fn.format.html":
=> /html[0]/body[1]/ul[63]/li[0] => [Texts differ]: expected " - This is intended for numeric types and indicates that the sign\n    should always be printed. Positive signs are never printed by\n    default, and the negative sign is only printed by default for the\n    ", found " - This is intended for numeric types and indicates that the sign\nshould always be printed. Positive signs are never printed by\ndefault, and the negative sign is only printed by default for the\n"
=> /html[0]/body[1]/ul[63]/li[0] => [Texts differ]: expected ")\n    should always be printed.", found ")\nshould always be printed."
=> /html[0]/body[1]/ul[63]/li[2] => [Texts differ]: expected " - This flag is indicates that the \"alternate\" form of printing should\n    be used. The alternate forms are:\n\n", found " - This flag is indicates that the \"alternate\" form of printing should\nbe used. The alternate forms are:\n"
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " - This is used to indicate for integer formats that the padding should\n    both be done with a ", found " - This is used to indicate for integer formats that the padding should\nboth be done with a "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " character as well as be sign-aware. A format\n    like ", found " character as well as be sign-aware. A format\nlike "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected ", while the\n    same format would yield ", found ", while the\nsame format would yield "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected ". Notice that\n    the negative version has one fewer zero than the positive version.\n    Note that padding zeroes are always placed after the sign (if any)\n    and before the digits. When used together with the ", found ". Notice that\nthe negative version has one fewer zero than the positive version.\nNote that padding zeroes are always placed after the sign (if any)\nand before the digits. When used together with the "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " flag, a similar\n    rule applies: padding zeroes are inserted after the prefix but before\n    the digits.", found " flag, a similar\nrule applies: padding zeroes are inserted after the prefix but before\nthe digits."
Differences spotted in "This function takes a string slice and emits it to the internal buffer\nafter applying the relevant formatting flags specified. The flags\nrecognized for generic strings are:\n\n* width - the minimum width of what to emit\n* fill/align - what to emit and where to emit it if the string\n               provided needs to be padded\n* precision - the maximum length to emit, the string is truncated if it\n              is longer than this length\n\nNotably this function ignores the `flag` parameters.":
=> /html[0]/body[1]/ul[1]/li[1] => [Texts differ]: expected "fill/align - what to emit and where to emit it if the string\n           provided needs to be padded", found "fill/align - what to emit and where to emit it if the string\nprovided needs to be padded"
=> /html[0]/body[1]/ul[1]/li[2] => [Texts differ]: expected "precision - the maximum length to emit, the string is truncated if it\n          is longer than this length", found "precision - the maximum length to emit, the string is truncated if it\nis longer than this length"
Differences spotted in "Utilities for formatting and printing `String`s\n\nThis module contains the runtime support for the [`format!`] syntax extension.\nThis macro is implemented in the compiler to emit calls to this module in\norder to format arguments at runtime into strings.\n\n# Usage\n\nThe [`format!`] macro is intended to be familiar to those coming from C\'s\n`printf`/`fprintf` functions or Python\'s `str.format` function.\n\nSome examples of the [`format!`] extension are:\n\n```\nformat!(\"Hello\");                 // => \"Hello\"\nformat!(\"Hello, {}!\", \"world\");   // => \"Hello, world!\"\nformat!(\"The number is {}\", 1);   // => \"The number is 1\"\nformat!(\"{:?}\", (3, 4));          // => \"(3, 4)\"\nformat!(\"{value}\", value=4);      // => \"4\"\nformat!(\"{} {}\", 1, 2);           // => \"1 2\"\nformat!(\"{:04}\", 42);             // => \"0042\" with leading zeros\n```\n\nFrom these, you can see that the first argument is a format string. It is\nrequired by the compiler for this to be a string literal; it cannot be a\nvariable passed in (in order to perform validity checking). The compiler\nwill then parse the format string and determine if the list of arguments\nprovided is suitable to pass to this format string.\n\n## Positional parameters\n\nEach formatting argument is allowed to specify which value argument it\'s\nreferencing, and if omitted it is assumed to be \"the next argument\". For\nexample, the format string `{} {} {}` would take three parameters, and they\nwould be formatted in the same order as they\'re given. The format string\n`{2} {1} {0}`, however, would format arguments in reverse order.\n\nThings can get a little tricky once you start intermingling the two types of\npositional specifiers. The \"next argument\" specifier can be thought of as an\niterator over the argument. Each time a \"next argument\" specifier is seen,\nthe iterator advances. This leads to behavior like this:\n\n```\nformat!(\"{1} {} {0} {}\", 1, 2); // => \"2 1 1 2\"\n```\n\nThe internal iterator over the argument has not been advanced by the time\nthe first `{}` is seen, so it prints the first argument. Then upon reaching\nthe second `{}`, the iterator has advanced forward to the second argument.\nEssentially, parameters which explicitly name their argument do not affect\nparameters which do not name an argument in terms of positional specifiers.\n\nA format string is required to use all of its arguments, otherwise it is a\ncompile-time error. You may refer to the same argument more than once in the\nformat string.\n\n## Named parameters\n\nRust itself does not have a Python-like equivalent of named parameters to a\nfunction, but the [`format!`] macro is a syntax extension which allows it to\nleverage named parameters. Named parameters are listed at the end of the\nargument list and have the syntax:\n\n```text\nidentifier \'=\' expression\n```\n\nFor example, the following [`format!`] expressions all use named argument:\n\n```\nformat!(\"{argument}\", argument = \"test\");   // => \"test\"\nformat!(\"{name} {}\", 1, name = 2);          // => \"2 1\"\nformat!(\"{a} {c} {b}\", a=\"a\", b=\'b\', c=3);  // => \"a 3 b\"\n```\n\nIt is not valid to put positional parameters (those without names) after\narguments which have names. Like with positional parameters, it is not\nvalid to provide named parameters that are unused by the format string.\n\n## Argument types\n\nEach argument\'s type is dictated by the format string.\nThere are various parameters which require a particular type, however.\nAn example is the `{:.*}` syntax, which sets the number of decimal places\nin floating-point types:\n\n```\nlet formatted_number = format!(\"{:.*}\", 2, 1.234567);\n\nassert_eq!(\"1.23\", formatted_number)\n```\n\nIf this syntax is used, then the number of characters to print precedes the\nactual object being formatted, and the number of characters must have the\ntype [`usize`].\n\n## Formatting traits\n\nWhen requesting that an argument be formatted with a particular type, you\nare actually requesting that an argument ascribes to a particular trait.\nThis allows multiple actual types to be formatted via `{:x}` (like [`i8`] as\nwell as [`isize`]).  The current mapping of types to traits is:\n\n* *nothing* ⇒ [`Display`]\n* `?` ⇒ [`Debug`]\n* `o` ⇒ [`Octal`](trait.Octal.html)\n* `x` ⇒ [`LowerHex`](trait.LowerHex.html)\n* `X` ⇒ [`UpperHex`](trait.UpperHex.html)\n* `p` ⇒ [`Pointer`](trait.Pointer.html)\n* `b` ⇒ [`Binary`]\n* `e` ⇒ [`LowerExp`](trait.LowerExp.html)\n* `E` ⇒ [`UpperExp`](trait.UpperExp.html)\n\nWhat this means is that any type of argument which implements the\n[`fmt::Binary`][`Binary`] trait can then be formatted with `{:b}`. Implementations\nare provided for these traits for a number of primitive types by the\nstandard library as well. If no format is specified (as in `{}` or `{:6}`),\nthen the format trait used is the [`Display`] trait.\n\nWhen implementing a format trait for your own type, you will have to\nimplement a method of the signature:\n\n```\n# #![allow(dead_code)]\n# use std::fmt;\n# struct Foo; // our custom type\n# impl fmt::Display for Foo {\nfn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n# write!(f, \"testing, testing\")\n# } }\n```\n\nYour type will be passed as `self` by-reference, and then the function\nshould emit output into the `f.buf` stream. It is up to each format trait\nimplementation to correctly adhere to the requested formatting parameters.\nThe values of these parameters will be listed in the fields of the\n[`Formatter`] struct. In order to help with this, the [`Formatter`] struct also\nprovides some helper methods.\n\nAdditionally, the return value of this function is [`fmt::Result`] which is a\ntype alias of [`Result`]`<(), `[`std::fmt::Error`]`>`. Formatting implementations\nshould ensure that they propagate errors from the [`Formatter`][`Formatter`] (e.g., when\ncalling [`write!`]) however, they should never return errors spuriously. That\nis, a formatting implementation must and may only return an error if the\npassed-in [`Formatter`] returns an error. This is because, contrary to what\nthe function signature might suggest, string formatting is an infallible\noperation. This function only returns a result because writing to the\nunderlying stream might fail and it must provide a way to propagate the fact\nthat an error has occurred back up the stack.\n\nAn example of implementing the formatting traits would look\nlike:\n\n```\nuse std::fmt;\n\n#[derive(Debug)]\nstruct Vector2D {\n    x: isize,\n    y: isize,\n}\n\nimpl fmt::Display for Vector2D {\n    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n        // The `f` value implements the `Write` trait, which is what the\n        // write! macro is expecting. Note that this formatting ignores the\n        // various flags provided to format strings.\n        write!(f, \"({}, {})\", self.x, self.y)\n    }\n}\n\n// Different traits allow different forms of output of a type. The meaning\n// of this format is to print the magnitude of a vector.\nimpl fmt::Binary for Vector2D {\n    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n        let magnitude = (self.x * self.x + self.y * self.y) as f64;\n        let magnitude = magnitude.sqrt();\n\n        // Respect the formatting flags by using the helper method\n        // `pad_integral` on the Formatter object. See the method\n        // documentation for details, and the function `pad` can be used\n        // to pad strings.\n        let decimals = f.precision().unwrap_or(3);\n        let string = format!(\"{:.*}\", decimals, magnitude);\n        f.pad_integral(true, \"\", &string)\n    }\n}\n\nfn main() {\n    let myvector = Vector2D { x: 3, y: 4 };\n\n    println!(\"{}\", myvector);       // => \"(3, 4)\"\n    println!(\"{:?}\", myvector);     // => \"Vector2D {x: 3, y:4}\"\n    println!(\"{:10.3b}\", myvector); // => \"     5.000\"\n}\n```\n\n### `fmt::Display` vs `fmt::Debug`\n\nThese two formatting traits have distinct purposes:\n\n- [`fmt::Display`][`Display`] implementations assert that the type can be faithfully\n  represented as a UTF-8 string at all times. It is **not** expected that\n  all types implement the [`Display`] trait.\n- [`fmt::Debug`][`Debug`] implementations should be implemented for **all** public types.\n  Output will typically represent the internal state as faithfully as possible.\n  The purpose of the [`Debug`] trait is to facilitate debugging Rust code. In\n  most cases, using `#[derive(Debug)]` is sufficient and recommended.\n\nSome examples of the output from both traits:\n\n```\nassert_eq!(format!(\"{} {:?}\", 3, 4), \"3 4\");\nassert_eq!(format!(\"{} {:?}\", \'a\', \'b\'), \"a \'b\'\");\nassert_eq!(format!(\"{} {:?}\", \"foo\\n\", \"bar\\n\"), \"foo\\n \\\"bar\\\\n\\\"\");\n```\n\n## Related macros\n\nThere are a number of related macros in the [`format!`] family. The ones that\nare currently implemented are:\n\n```ignore (only-for-syntax-highlight)\nformat!      // described above\nwrite!       // first argument is a &mut io::Write, the destination\nwriteln!     // same as write but appends a newline\nprint!       // the format string is printed to the standard output\nprintln!     // same as print but appends a newline\nformat_args! // described below.\n```\n\n### `write!`\n\nThis and [`writeln!`] are two macros which are used to emit the format string\nto a specified stream. This is used to prevent intermediate allocations of\nformat strings and instead directly write the output. Under the hood, this\nfunction is actually invoking the [`write_fmt`] function defined on the\n[`std::io::Write`] trait. Example usage is:\n\n```\n# #![allow(unused_must_use)]\nuse std::io::Write;\nlet mut w = Vec::new();\nwrite!(&mut w, \"Hello {}!\", \"world\");\n```\n\n### `print!`\n\nThis and [`println!`] emit their output to stdout. Similarly to the [`write!`]\nmacro, the goal of these macros is to avoid intermediate allocations when\nprinting output. Example usage is:\n\n```\nprint!(\"Hello {}!\", \"world\");\nprintln!(\"I have a newline {}\", \"character at the end\");\n```\n\n### `format_args!`\n\nThis is a curious macro which is used to safely pass around\nan opaque object describing the format string. This object\ndoes not require any heap allocations to create, and it only\nreferences information on the stack. Under the hood, all of\nthe related macros are implemented in terms of this. First\noff, some example usage is:\n\n```\n# #![allow(unused_must_use)]\nuse std::fmt;\nuse std::io::{self, Write};\n\nlet mut some_writer = io::stdout();\nwrite!(&mut some_writer, \"{}\", format_args!(\"print with a {}\", \"macro\"));\n\nfn my_fmt_fn(args: fmt::Arguments) {\n    write!(&mut io::stdout(), \"{}\", args);\n}\nmy_fmt_fn(format_args!(\", or a {} too\", \"function\"));\n```\n\nThe result of the [`format_args!`] macro is a value of type [`fmt::Arguments`].\nThis structure can then be passed to the [`write`] and [`format`] functions\ninside this module in order to process the format string.\nThe goal of this macro is to even further prevent intermediate allocations\nwhen dealing formatting strings.\n\nFor example, a logging library could use the standard formatting syntax, but\nit would internally pass around this structure until it has been determined\nwhere output should go to.\n\n# Syntax\n\nThe syntax for the formatting language used is drawn from other languages,\nso it should not be too alien. Arguments are formatted with Python-like\nsyntax, meaning that arguments are surrounded by `{}` instead of the C-like\n`%`. The actual grammar for the formatting syntax is:\n\n```text\nformat_string := <text> [ maybe-format <text> ] *\nmaybe-format := \'{\' \'{\' | \'}\' \'}\' | <format>\nformat := \'{\' [ argument ] [ \':\' format_spec ] \'}\'\nargument := integer | identifier\n\nformat_spec := [[fill]align][sign][\'#\'][\'0\'][width][\'.\' precision][type]\nfill := character\nalign := \'<\' | \'^\' | \'>\'\nsign := \'+\' | \'-\'\nwidth := count\nprecision := count | \'*\'\ntype := identifier | \'\'\ncount := parameter | integer\nparameter := argument \'$\'\n```\n\n# Formatting Parameters\n\nEach argument being formatted can be transformed by a number of formatting\nparameters (corresponding to `format_spec` in the syntax above). These\nparameters affect the string representation of what\'s being formatted. This\nsyntax draws heavily from Python\'s, so it may seem a bit familiar.\n\n## Fill/Alignment\n\nThe fill character is provided normally in conjunction with the `width`\nparameter. This indicates that if the value being formatted is smaller than\n`width` some extra characters will be printed around it. The extra\ncharacters are specified by `fill`, and the alignment can be one of the\nfollowing options:\n\n* `<` - the argument is left-aligned in `width` columns\n* `^` - the argument is center-aligned in `width` columns\n* `>` - the argument is right-aligned in `width` columns\n\nNote that alignment may not be implemented by some types. A good way\nto ensure padding is applied is to format your input, then use this\nresulting string to pad your output.\n\n## Sign/`#`/`0`\n\nThese can all be interpreted as flags for a particular formatter.\n\n* `+` - This is intended for numeric types and indicates that the sign\n        should always be printed. Positive signs are never printed by\n        default, and the negative sign is only printed by default for the\n        `Signed` trait. This flag indicates that the correct sign (`+` or `-`)\n        should always be printed.\n* `-` - Currently not used\n* `#` - This flag is indicates that the \"alternate\" form of printing should\n        be used. The alternate forms are:\n    * `#?` - pretty-print the [`Debug`] formatting\n    * `#x` - precedes the argument with a `0x`\n    * `#X` - precedes the argument with a `0x`\n    * `#b` - precedes the argument with a `0b`\n    * `#o` - precedes the argument with a `0o`\n* `0` - This is used to indicate for integer formats that the padding should\n        both be done with a `0` character as well as be sign-aware. A format\n        like `{:08}` would yield `00000001` for the integer `1`, while the\n        same format would yield `-0000001` for the integer `-1`. Notice that\n        the negative version has one fewer zero than the positive version.\n        Note that padding zeroes are always placed after the sign (if any)\n        and before the digits. When used together with the `#` flag, a similar\n        rule applies: padding zeroes are inserted after the prefix but before\n        the digits.\n\n## Width\n\nThis is a parameter for the \"minimum width\" that the format should take up.\nIf the value\'s string does not fill up this many characters, then the\npadding specified by fill/alignment will be used to take up the required\nspace.\n\nThe default fill/alignment for non-numerics is a space and left-aligned. The\ndefaults for numeric formatters is also a space but with right-alignment. If\nthe `0` flag is specified for numerics, then the implicit fill character is\n`0`.\n\nThe value for the width can also be provided as a [`usize`] in the list of\nparameters by using the dollar syntax indicating that the second argument is\na [`usize`] specifying the width, for example:\n\n```\n// All of these print \"Hello x    !\"\nprintln!(\"Hello {:5}!\", \"x\");\nprintln!(\"Hello {:1$}!\", \"x\", 5);\nprintln!(\"Hello {1:0$}!\", 5, \"x\");\nprintln!(\"Hello {:width$}!\", \"x\", width = 5);\n```\n\nReferring to an argument with the dollar syntax does not affect the \"next\nargument\" counter, so it\'s usually a good idea to refer to arguments by\nposition, or use named arguments.\n\n## Precision\n\nFor non-numeric types, this can be considered a \"maximum width\". If the resulting string is\nlonger than this width, then it is truncated down to this many characters and that truncated\nvalue is emitted with proper `fill`, `alignment` and `width` if those parameters are set.\n\nFor integral types, this is ignored.\n\nFor floating-point types, this indicates how many digits after the decimal point should be\nprinted.\n\nThere are three possible ways to specify the desired `precision`:\n\n1. An integer `.N`:\n\n   the integer `N` itself is the precision.\n\n2. An integer or name followed by dollar sign `.N$`:\n\n   use format *argument* `N` (which must be a `usize`) as the precision.\n\n3. An asterisk `.*`:\n\n   `.*` means that this `{...}` is associated with *two* format inputs rather than one: the\n   first input holds the `usize` precision, and the second holds the value to print.  Note that\n   in this case, if one uses the format string `{<arg>:<spec>.*}`, then the `<arg>` part refers\n   to the *value* to print, and the `precision` must come in the input preceding `<arg>`.\n\nFor example, the following calls all print the same thing `Hello x is 0.01000`:\n\n```\n// Hello {arg 0 (\"x\")} is {arg 1 (0.01) with precision specified inline (5)}\nprintln!(\"Hello {0} is {1:.5}\", \"x\", 0.01);\n\n// Hello {arg 1 (\"x\")} is {arg 2 (0.01) with precision specified in arg 0 (5)}\nprintln!(\"Hello {1} is {2:.0$}\", 5, \"x\", 0.01);\n\n// Hello {arg 0 (\"x\")} is {arg 2 (0.01) with precision specified in arg 1 (5)}\nprintln!(\"Hello {0} is {2:.1$}\", \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {second of next two args (0.01) with precision\n//                          specified in first of next two args (5)}\nprintln!(\"Hello {} is {:.*}\",    \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {arg 2 (0.01) with precision\n//                          specified in its predecessor (5)}\nprintln!(\"Hello {} is {2:.*}\",   \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {arg \"number\" (0.01) with precision specified\n//                          in arg \"prec\" (5)}\nprintln!(\"Hello {} is {number:.prec$}\", \"x\", prec = 5, number = 0.01);\n```\n\nWhile these:\n\n```\nprintln!(\"{}, `{name:.*}` has 3 fractional digits\", \"Hello\", 3, name=1234.56);\nprintln!(\"{}, `{name:.*}` has 3 characters\", \"Hello\", 3, name=\"1234.56\");\nprintln!(\"{}, `{name:>8.*}` has 3 right-aligned characters\", \"Hello\", 3, name=\"1234.56\");\n```\n\nprint two significantly different things:\n\n```text\nHello, `1234.560` has 3 fractional digits\nHello, `123` has 3 characters\nHello, `     123` has 3 right-aligned characters\n```\n\n# Escaping\n\nThe literal characters `{` and `}` may be included in a string by preceding\nthem with the same character. For example, the `{` character is escaped with\n`{{` and the `}` character is escaped with `}}`.\n\n[`format!`]: ../../macro.format.html\n[`usize`]: ../../std/primitive.usize.html\n[`isize`]: ../../std/primitive.isize.html\n[`i8`]: ../../std/primitive.i8.html\n[`Display`]: trait.Display.html\n[`Binary`]: trait.Binary.html\n[`fmt::Result`]: type.Result.html\n[`Result`]: ../../std/result/enum.Result.html\n[`std::fmt::Error`]: struct.Error.html\n[`Formatter`]: struct.Formatter.html\n[`write!`]: ../../std/macro.write.html\n[`Debug`]: trait.Debug.html\n[`format!`]: ../../std/macro.format.html\n[`writeln!`]: ../../std/macro.writeln.html\n[`write_fmt`]: ../../std/io/trait.Write.html#method.write_fmt\n[`std::io::Write`]: ../../std/io/trait.Write.html\n[`println!`]: ../../std/macro.println.html\n[`write!`]: ../../std/macro.write.html\n[`format_args!`]: ../../std/macro.format_args.html\n[`fmt::Arguments`]: struct.Arguments.html\n[`write`]: fn.write.html\n[`format`]: fn.format.html":
=> /html[0]/body[1]/ul[63]/li[0] => [Texts differ]: expected " - This is intended for numeric types and indicates that the sign\n    should always be printed. Positive signs are never printed by\n    default, and the negative sign is only printed by default for the\n    ", found " - This is intended for numeric types and indicates that the sign\nshould always be printed. Positive signs are never printed by\ndefault, and the negative sign is only printed by default for the\n"
=> /html[0]/body[1]/ul[63]/li[0] => [Texts differ]: expected ")\n    should always be printed.", found ")\nshould always be printed."
=> /html[0]/body[1]/ul[63]/li[2] => [Texts differ]: expected " - This flag is indicates that the \"alternate\" form of printing should\n    be used. The alternate forms are:\n\n", found " - This flag is indicates that the \"alternate\" form of printing should\nbe used. The alternate forms are:\n"
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " - This is used to indicate for integer formats that the padding should\n    both be done with a ", found " - This is used to indicate for integer formats that the padding should\nboth be done with a "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " character as well as be sign-aware. A format\n    like ", found " character as well as be sign-aware. A format\nlike "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected ", while the\n    same format would yield ", found ", while the\nsame format would yield "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected ". Notice that\n    the negative version has one fewer zero than the positive version.\n    Note that padding zeroes are always placed after the sign (if any)\n    and before the digits. When used together with the ", found ". Notice that\nthe negative version has one fewer zero than the positive version.\nNote that padding zeroes are always placed after the sign (if any)\nand before the digits. When used together with the "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " flag, a similar\n    rule applies: padding zeroes are inserted after the prefix but before\n    the digits.", found " flag, a similar\nrule applies: padding zeroes are inserted after the prefix but before\nthe digits."
Differences spotted in "This function takes a string slice and emits it to the internal buffer\nafter applying the relevant formatting flags specified. The flags\nrecognized for generic strings are:\n\n* width - the minimum width of what to emit\n* fill/align - what to emit and where to emit it if the string\n               provided needs to be padded\n* precision - the maximum length to emit, the string is truncated if it\n              is longer than this length\n\nNotably this function ignores the `flag` parameters.":
=> /html[0]/body[1]/ul[1]/li[1] => [Texts differ]: expected "fill/align - what to emit and where to emit it if the string\n           provided needs to be padded", found "fill/align - what to emit and where to emit it if the string\nprovided needs to be padded"
=> /html[0]/body[1]/ul[1]/li[2] => [Texts differ]: expected "precision - the maximum length to emit, the string is truncated if it\n          is longer than this length", found "precision - the maximum length to emit, the string is truncated if it\nis longer than this length"
Differences spotted in "Constructs a `Layout` from a given `size` and `align`,\nor returns `None` if any of the following conditions\nare not met:\n\n* `align` must be a power of two,\n\n* `align` must not exceed 2^31 (i.e. `1 << 31`),\n\n* `size`, when rounded up to the nearest multiple of `align`,\n   must not overflow (i.e. the rounded value must be less than\n   `usize::MAX`).":
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [Texts differ]: expected " must not exceed 2", found " must not exceed 2^31 (i.e. "
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [Tags differ]: expected "sup", found "code"
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [Texts differ]: expected " (i.e. ", found "),"
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [One element is missing]: expected "code"
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [One element is missing]: expected ","
Differences spotted in "Creates a layout, bypassing all checks.\n\n# Safety\n\nThis function is unsafe as it does not verify that `align` is\na power-of-two that is also less than or equal to 2^31, nor\nthat `size` aligned to `align` fits within the address space\n(i.e. the `Layout::from_size_align` preconditions).":
=> /html[0]/body[1]/p[2] => [Texts differ]: expected " is\na power-of-two that is also less than or equal to 2", found " is\na power-of-two that is also less than or equal to 2^31, nor\nthat "
=> /html[0]/body[1]/p[2] => [Tags differ]: expected "sup", found "code"
=> /html[0]/body[1]/p[2] => [Texts differ]: expected " nor\nthat ", found " aligned to "
=> /html[0]/body[1]/p[2]/code[1] => [Texts differ]: expected "size", found "align"
=> /html[0]/body[1]/p[2] => [Texts differ]: expected " aligned to ", found " fits within the address space\n(i.e. the "
=> /html[0]/body[1]/p[2]/code[2] => [Texts differ]: expected "align", found "Layout::from_size_align"
=> /html[0]/body[1]/p[2] => [Texts differ]: expected " fits within the address space\n(i.e. the ", found " preconditions)."
=> /html[0]/body[1]/p[2] => [One element is missing]: expected "code"
=> /html[0]/body[1]/p[2] => [One element is missing]: expected ""
Differences spotted in "Creates a layout describing the record for `self` followed by\n`next` with no additional padding between the two. Since no\npadding is inserted, the alignment of `next` is irrelevant,\nand is not incorporated *at all* into the resulting layout.\n\nReturns `(k, offset)`, where `k` is layout of the concatenated\nrecord and `offset` is the relative location, in bytes, of the\nstart of the `next` embedded within the concatenated record\n(assuming that the record itself starts at offset 0).\n\n(The `offset` is always the same as `self.size()`; we use this\n signature out of convenience in matching the signature of\n `extend`.)\n\nOn arithmetic overflow, returns `None`.":
=> /html[0]/body[1]/p[2] => [Texts differ]: expected "; we use this\n signature out of convenience in matching the signature of\n ", found "; we use this\nsignature out of convenience in matching the signature of\n"
Differences spotted in "Checks if the value is an ASCII punctuation character: U+0021 ... U+002F `! \" # $ % & \' ( ) * + , - . /` U+003A ... U+0040 `: ; < = > ? @` U+005B ... U+0060 `[ \\\\ ] ^ _ \\`` U+007B ... U+007E`{ | } ~` For strings, true if all characters in the string are ASCII punctuation. [Read more](../std/ascii/trait.AsciiExt.html#method.is_ascii_punctuation)":
=> /html[0]/body[1]/p[0]/code[2] => [Texts differ]: expected "[ \\\\ ] ^ _ \\", found "[ \\\\ ] ^ _ \\`` U+007B ... U+007E"
=> /html[0]/body[1]/p[0] => [Types differ]: expected "code", found ""
=> /html[0]/body[1]/p[0] => [Types differ]: expected "", found "a"
=> /html[0]/body[1]/p[0] => [One element is missing]: expected "a"
Differences spotted in "Checks if the value is an ASCII punctuation character: U+0021 ... U+002F `! \" # $ % & \' ( ) * + , - . /` U+003A ... U+0040 `: ; < = > ? @` U+005B ... U+0060 `[ \\\\ ] ^ _ \\`` U+007B ... U+007E`{ | } ~` For strings, true if all characters in the string are ASCII punctuation. [Read more](../std/ascii/trait.AsciiExt.html#method.is_ascii_punctuation)":
=> /html[0]/body[1]/p[0]/code[2] => [Texts differ]: expected "[ \\\\ ] ^ _ \\", found "[ \\\\ ] ^ _ \\`` U+007B ... U+007E"
=> /html[0]/body[1]/p[0] => [Types differ]: expected "code", found ""
=> /html[0]/body[1]/p[0] => [Types differ]: expected "", found "a"
=> /html[0]/body[1]/p[0] => [One element is missing]: expected "a"
Differences spotted in "Checks if the value is an ASCII punctuation character: U+0021 ... U+002F `! \" # $ % & \' ( ) * + , - . /` U+003A ... U+0040 `: ; < = > ? @` U+005B ... U+0060 `[ \\\\ ] ^ _ \\`` U+007B ... U+007E`{ | } ~` For strings, true if all characters in the string are ASCII punctuation. [Read more](../std/ascii/trait.AsciiExt.html#method.is_ascii_punctuation)":
=> /html[0]/body[1]/p[0]/code[2] => [Texts differ]: expected "[ \\\\ ] ^ _ \\", found "[ \\\\ ] ^ _ \\`` U+007B ... U+007E"
=> /html[0]/body[1]/p[0] => [Types differ]: expected "code", found ""
=> /html[0]/body[1]/p[0] => [Types differ]: expected "", found "a"
=> /html[0]/body[1]/p[0] => [One element is missing]: expected "a"
Differences spotted in "Checks if the value is an ASCII punctuation character: U+0021 ... U+002F `! \" # $ % & \' ( ) * + , - . /` U+003A ... U+0040 `: ; < = > ? @` U+005B ... U+0060 `[ \\\\ ] ^ _ \\`` U+007B ... U+007E`{ | } ~` For strings, true if all characters in the string are ASCII punctuation. [Read more](../std/ascii/trait.AsciiExt.html#method.is_ascii_punctuation)":
=> /html[0]/body[1]/p[0]/code[2] => [Texts differ]: expected "[ \\\\ ] ^ _ \\", found "[ \\\\ ] ^ _ \\`` U+007B ... U+007E"
=> /html[0]/body[1]/p[0] => [Types differ]: expected "code", found ""
=> /html[0]/body[1]/p[0] => [Types differ]: expected "", found "a"
=> /html[0]/body[1]/p[0] => [One element is missing]: expected "a"
Differences spotted in "Constructs a `Layout` from a given `size` and `align`,\nor returns `None` if any of the following conditions\nare not met:\n\n* `align` must be a power of two,\n\n* `align` must not exceed 2^31 (i.e. `1 << 31`),\n\n* `size`, when rounded up to the nearest multiple of `align`,\n   must not overflow (i.e. the rounded value must be less than\n   `usize::MAX`).":
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [Texts differ]: expected " must not exceed 2", found " must not exceed 2^31 (i.e. "
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [Tags differ]: expected "sup", found "code"
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [Texts differ]: expected " (i.e. ", found "),"
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [One element is missing]: expected "code"
=> /html[0]/body[1]/ul[1]/li[1]/p[0] => [One element is missing]: expected ","
Differences spotted in "Creates a layout, bypassing all checks.\n\n# Safety\n\nThis function is unsafe as it does not verify that `align` is\na power-of-two that is also less than or equal to 2^31, nor\nthat `size` aligned to `align` fits within the address space\n(i.e. the `Layout::from_size_align` preconditions).":
=> /html[0]/body[1]/p[2] => [Texts differ]: expected " is\na power-of-two that is also less than or equal to 2", found " is\na power-of-two that is also less than or equal to 2^31, nor\nthat "
=> /html[0]/body[1]/p[2] => [Tags differ]: expected "sup", found "code"
=> /html[0]/body[1]/p[2] => [Texts differ]: expected " nor\nthat ", found " aligned to "
=> /html[0]/body[1]/p[2]/code[1] => [Texts differ]: expected "size", found "align"
=> /html[0]/body[1]/p[2] => [Texts differ]: expected " aligned to ", found " fits within the address space\n(i.e. the "
=> /html[0]/body[1]/p[2]/code[2] => [Texts differ]: expected "align", found "Layout::from_size_align"
=> /html[0]/body[1]/p[2] => [Texts differ]: expected " fits within the address space\n(i.e. the ", found " preconditions)."
=> /html[0]/body[1]/p[2] => [One element is missing]: expected "code"
=> /html[0]/body[1]/p[2] => [One element is missing]: expected ""
Differences spotted in "Creates a layout describing the record for `self` followed by\n`next` with no additional padding between the two. Since no\npadding is inserted, the alignment of `next` is irrelevant,\nand is not incorporated *at all* into the resulting layout.\n\nReturns `(k, offset)`, where `k` is layout of the concatenated\nrecord and `offset` is the relative location, in bytes, of the\nstart of the `next` embedded within the concatenated record\n(assuming that the record itself starts at offset 0).\n\n(The `offset` is always the same as `self.size()`; we use this\n signature out of convenience in matching the signature of\n `extend`.)\n\nOn arithmetic overflow, returns `None`.":
=> /html[0]/body[1]/p[2] => [Texts differ]: expected "; we use this\n signature out of convenience in matching the signature of\n ", found "; we use this\nsignature out of convenience in matching the signature of\n"
Differences spotted in "Constructs a new `Command` for launching the program at\npath `program`, with the following default configuration:\n\n* No arguments to the program\n* Inherit the current process\'s environment\n* Inherit the current process\'s working directory\n* Inherit stdin/stdout/stderr for `spawn` or `status`, but create pipes for `output`\n\nBuilder methods are provided to change these defaults and\notherwise configure the process.\n\nIf `program` is not an absolute path, the `PATH` will be searched in\nan OS-defined way.\n\nThe search path to be used may be controlled by setting the\n`PATH` environment variable on the Command,\nbut this has some implementation limitations on Windows\n(see https://github.com/rust-lang/rust/issues/37519).\n\n# Examples\n\nBasic usage:\n\n```no_run\nuse std::process::Command;\n\nCommand::new(\"sh\")\n        .spawn()\n        .expect(\"sh command failed to start\");\n```":
=> /html[0]/body[1]/p[4] => [Texts differ]: expected " environment variable on the Command,\nbut this has some implementation limitations on Windows\n(see ", found " environment variable on the Command,\nbut this has some implementation limitations on Windows\n(see https://github.com/rust-lang/rust/issues/37519)."
=> /html[0]/body[1]/p[4] => [One element is missing]: expected "a"
=> /html[0]/body[1]/p[4] => [One element is missing]: expected "."
Differences spotted in "Seeks to a given position and reads a number of bytes.\n\nReturns the number of bytes read.\n\nThe offset is relative to the start of the file and thus independent\nfrom the current cursor. The current cursor **is** affected by this\nfunction, it is set to the end of the read.\n\nReading beyond the end of the file will always return with a length of\n0.\n\nNote that similar to `File::read`, it is not an error to return with a\nshort read. When returning from such a short read, the file pointer is\nstill updated.\n\n# Examples\n\n```no_run\nuse std::io;\nuse std::fs::File;\nuse std::os::windows::prelude::*;\n\n# fn foo() -> io::Result<()> {\nlet mut file = File::open(\"foo.txt\")?;\nlet mut buffer = [0; 10];\n\n// Read 10 bytes, starting 72 bytes from the\n// start of the file.\nfile.seek_read(&mut buffer[..], 72)?;\n# Ok(())\n# }\n```":
=> /html[0]/body[1]/p[3] => [Texts differ]: expected "Reading beyond the end of the file will always return with a length of\n0.", found "Reading beyond the end of the file will always return with a length of"
=> /html[0]/body[1] => [Tags differ]: expected "p", found "ol"
=> /html[0]/body[1] => [Tags differ]: expected "h1", found "p"
=> /html[0]/body[1] => [Tags differ]: expected "pre", found "h1"
=> /html[0]/body[1] => [Unexpected element "pre"]: found "<pre class=\"rust rust-example-rendered\"><span class=\"kw\">use</span> <span class=\"ident\">std</span>::<span class=\"ident\">io</span>;\n<span class=\"kw\">use</span> <span class=\"ident\">std</span>::<span class=\"ident\">fs</span>::<span class=\"ident\">File</span>;\n<span class=\"kw\">use</span> <span class=\"ident\">std</span>::<span class=\"ident\">os</span>::<span class=\"ident\">windows</span>::<span class=\"ident\">prelude</span>::<span class=\"kw-2\">*</span>;\n\n<span class=\"kw\">let</span> <span class=\"kw-2\">mut</span> <span class=\"ident\">file</span> <span class=\"op\">=</span> <span class=\"ident\">File</span>::<span class=\"ident\">open</span>(<span class=\"string\">\"foo.txt\"</span>)<span class=\"question-mark\">?</span>;\n<span class=\"kw\">let</span> <span class=\"kw-2\">mut</span> <span class=\"ident\">buffer</span> <span class=\"op\">=</span> [<span class=\"number\">0</span>; <span class=\"number\">10</span>];\n\n<span class=\"comment\">// Read 10 bytes, starting 72 bytes from the</span>\n<span class=\"comment\">// start of the file.</span>\n<span class=\"ident\">file</span>.<span class=\"ident\">seek_read</span>(<span class=\"kw-2\">&amp;</span><span class=\"kw-2\">mut</span> <span class=\"ident\">buffer</span>[..], <span class=\"number\">72</span>)<span class=\"question-mark\">?</span>;<a class=\"test-arrow\" target=\"_blank\" href=\"https://play.rust-lang.org/?code=fn%20main()%20%7B%0Ause%20std%3A%3Aio%3B%0Ause%20std%3A%3Afs%3A%3AFile%3B%0Ause%20std%3A%3Aos%3A%3Awindows%3A%3Aprelude%3A%3A*%3B%0A%0Afn%20foo()%20-%3E%20io%3A%3AResult%3C()%3E%20%7B%0Alet%20mut%20file%20%3D%20File%3A%3Aopen(%22foo.txt%22)%3F%3B%0Alet%20mut%20buffer%20%3D%20%5B0%3B%2010%5D%3B%0A%0A%2F%2F%20Read%2010%20bytes%2C%20starting%2072%20bytes%20from%20the%0A%2F%2F%20start%20of%20the%20file.%0Afile.seek_read(%26mut%20buffer%5B..%5D%2C%2072)%3F%3B%0AOk(())%0A%7D%0A%7D\">Run</a></pre>"
Differences spotted in "Sends data on the socket to the given address. On success, returns the\nnumber of bytes written.\n\nAddress type can be any implementor of [`ToSocketAddrs`] trait. See its\ndocumentation for concrete examples.\n\nThis will return an error when the IP version of the local socket\ndoes not match that returned from [`ToSocketAddrs`].\n\nSee https://github.com/rust-lang/rust/issues/34202 for more details.\n\n[`ToSocketAddrs`]: ../../std/net/trait.ToSocketAddrs.html\n\n# Examples\n\n```no_run\nuse std::net::UdpSocket;\n\nlet socket = UdpSocket::bind(\"127.0.0.1:34254\").expect(\"couldn\'t bind to address\");\nsocket.send_to(&[0; 10], \"127.0.0.1:4242\").expect(\"couldn\'t send data\");\n```":
=> /html[0]/body[1]/p[3] => [Texts differ]: expected "See ", found "See https://github.com/rust-lang/rust/issues/34202 for more details."
=> /html[0]/body[1]/p[3] => [One element is missing]: expected "a"
=> /html[0]/body[1]/p[3] => [One element is missing]: expected ""
Differences spotted in "Collection types.\n\nRust\'s standard collection library provides efficient implementations of the\nmost common general purpose programming data structures. By using the\nstandard implementations, it should be possible for two libraries to\ncommunicate without significant data conversion.\n\nTo get this out of the way: you should probably just use [`Vec`] or [`HashMap`].\nThese two collections cover most use cases for generic data storage and\nprocessing. They are exceptionally good at doing what they do. All the other\ncollections in the standard library have specific use cases where they are\nthe optimal choice, but these cases are borderline *niche* in comparison.\nEven when `Vec` and `HashMap` are technically suboptimal, they\'re probably a\ngood enough choice to get started.\n\nRust\'s collections can be grouped into four major categories:\n\n* Sequences: [`Vec`], [`VecDeque`], [`LinkedList`]\n* Maps: [`HashMap`], [`BTreeMap`]\n* Sets: [`HashSet`], [`BTreeSet`]\n* Misc: [`BinaryHeap`]\n\n# When Should You Use Which Collection?\n\nThese are fairly high-level and quick break-downs of when each collection\nshould be considered. Detailed discussions of strengths and weaknesses of\nindividual collections can be found on their own documentation pages.\n\n### Use a `Vec` when:\n* You want to collect items up to be processed or sent elsewhere later, and\n  don\'t care about any properties of the actual values being stored.\n* You want a sequence of elements in a particular order, and will only be\n  appending to (or near) the end.\n* You want a stack.\n* You want a resizable array.\n* You want a heap-allocated array.\n\n### Use a `VecDeque` when:\n* You want a [`Vec`] that supports efficient insertion at both ends of the\n  sequence.\n* You want a queue.\n* You want a double-ended queue (deque).\n\n### Use a `LinkedList` when:\n* You want a [`Vec`] or [`VecDeque`] of unknown size, and can\'t tolerate\n  amortization.\n* You want to efficiently split and append lists.\n* You are *absolutely* certain you *really*, *truly*, want a doubly linked\n  list.\n\n### Use a `HashMap` when:\n* You want to associate arbitrary keys with an arbitrary value.\n* You want a cache.\n* You want a map, with no extra functionality.\n\n### Use a `BTreeMap` when:\n* You\'re interested in what the smallest or largest key-value pair is.\n* You want to find the largest or smallest key that is smaller or larger\n  than something.\n* You want to be able to get all of the entries in order on-demand.\n* You want a map sorted by its keys.\n\n### Use the `Set` variant of any of these `Map`s when:\n* You just want to remember which keys you\'ve seen.\n* There is no meaningful value to associate with your keys.\n* You just want a set.\n\n### Use a `BinaryHeap` when:\n\n* You want to store a bunch of elements, but only ever want to process the\n  \"biggest\" or \"most important\" one at any given time.\n* You want a priority queue.\n\n# Performance\n\nChoosing the right collection for the job requires an understanding of what\neach collection is good at. Here we briefly summarize the performance of\ndifferent collections for certain important operations. For further details,\nsee each type\'s documentation, and note that the names of actual methods may\ndiffer from the tables below on certain collections.\n\nThroughout the documentation, we will follow a few conventions. For all\noperations, the collection\'s size is denoted by n. If another collection is\ninvolved in the operation, it contains m elements. Operations which have an\n*amortized* cost are suffixed with a `*`. Operations with an *expected*\ncost are suffixed with a `~`.\n\nAll amortized costs are for the potential need to resize when capacity is\nexhausted. If a resize occurs it will take O(n) time. Our collections never\nautomatically shrink, so removal operations aren\'t amortized. Over a\nsufficiently large series of operations, the average cost per operation will\ndeterministically equal the given cost.\n\nOnly [`HashMap`] has expected costs, due to the probabilistic nature of hashing.\nIt is theoretically possible, though very unlikely, for [`HashMap`] to\nexperience worse performance.\n\n## Sequences\n\n|                | get(i)         | insert(i)       | remove(i)      | append | split_off(i)   |\n|----------------|----------------|-----------------|----------------|--------|----------------|\n| [`Vec`]        | O(1)           | O(n-i)*         | O(n-i)         | O(m)*  | O(n-i)         |\n| [`VecDeque`]   | O(1)           | O(min(i, n-i))* | O(min(i, n-i)) | O(m)*  | O(min(i, n-i)) |\n| [`LinkedList`] | O(min(i, n-i)) | O(min(i, n-i))  | O(min(i, n-i)) | O(1)   | O(min(i, n-i)) |\n\nNote that where ties occur, [`Vec`] is generally going to be faster than [`VecDeque`], and\n[`VecDeque`] is generally going to be faster than [`LinkedList`].\n\n## Maps\n\nFor Sets, all operations have the cost of the equivalent Map operation.\n\n|              | get       | insert   | remove   | predecessor | append |\n|--------------|-----------|----------|----------|-------------|--------|\n| [`HashMap`]  | O(1)~     | O(1)~*   | O(1)~    | N/A         | N/A    |\n| [`BTreeMap`] | O(log n)  | O(log n) | O(log n) | O(log n)    | O(n+m) |\n\n# Correct and Efficient Usage of Collections\n\nOf course, knowing which collection is the right one for the job doesn\'t\ninstantly permit you to use it correctly. Here are some quick tips for\nefficient and correct usage of the standard collections in general. If\nyou\'re interested in how to use a specific collection in particular, consult\nits documentation for detailed discussion and code examples.\n\n## Capacity Management\n\nMany collections provide several constructors and methods that refer to\n\"capacity\". These collections are generally built on top of an array.\nOptimally, this array would be exactly the right size to fit only the\nelements stored in the collection, but for the collection to do this would\nbe very inefficient. If the backing array was exactly the right size at all\ntimes, then every time an element is inserted, the collection would have to\ngrow the array to fit it. Due to the way memory is allocated and managed on\nmost computers, this would almost surely require allocating an entirely new\narray and copying every single element from the old one into the new one.\nHopefully you can see that this wouldn\'t be very efficient to do on every\noperation.\n\nMost collections therefore use an *amortized* allocation strategy. They\ngenerally let themselves have a fair amount of unoccupied space so that they\nonly have to grow on occasion. When they do grow, they allocate a\nsubstantially larger array to move the elements into so that it will take a\nwhile for another grow to be required. While this strategy is great in\ngeneral, it would be even better if the collection *never* had to resize its\nbacking array. Unfortunately, the collection itself doesn\'t have enough\ninformation to do this itself. Therefore, it is up to us programmers to give\nit hints.\n\nAny `with_capacity` constructor will instruct the collection to allocate\nenough space for the specified number of elements. Ideally this will be for\nexactly that many elements, but some implementation details may prevent\nthis. [`Vec`] and [`VecDeque`] can be relied on to allocate exactly the\nrequested amount, though. Use `with_capacity` when you know exactly how many\nelements will be inserted, or at least have a reasonable upper-bound on that\nnumber.\n\nWhen anticipating a large influx of elements, the `reserve` family of\nmethods can be used to hint to the collection how much room it should make\nfor the coming items. As with `with_capacity`, the precise behavior of\nthese methods will be specific to the collection of interest.\n\nFor optimal performance, collections will generally avoid shrinking\nthemselves. If you believe that a collection will not soon contain any more\nelements, or just really need the memory, the `shrink_to_fit` method prompts\nthe collection to shrink the backing array to the minimum size capable of\nholding its elements.\n\nFinally, if ever you\'re interested in what the actual capacity of the\ncollection is, most collections provide a `capacity` method to query this\ninformation on demand. This can be useful for debugging purposes, or for\nuse with the `reserve` methods.\n\n## Iterators\n\nIterators are a powerful and robust mechanism used throughout Rust\'s\nstandard libraries. Iterators provide a sequence of values in a generic,\nsafe, efficient and convenient way. The contents of an iterator are usually\n*lazily* evaluated, so that only the values that are actually needed are\never actually produced, and no allocation need be done to temporarily store\nthem. Iterators are primarily consumed using a `for` loop, although many\nfunctions also take iterators where a collection or sequence of values is\ndesired.\n\nAll of the standard collections provide several iterators for performing\nbulk manipulation of their contents. The three primary iterators almost\nevery collection should provide are `iter`, `iter_mut`, and `into_iter`.\nSome of these are not provided on collections where it would be unsound or\nunreasonable to provide them.\n\n`iter` provides an iterator of immutable references to all the contents of a\ncollection in the most \"natural\" order. For sequence collections like [`Vec`],\nthis means the items will be yielded in increasing order of index starting\nat 0. For ordered collections like [`BTreeMap`], this means that the items\nwill be yielded in sorted order. For unordered collections like [`HashMap`],\nthe items will be yielded in whatever order the internal representation made\nmost convenient. This is great for reading through all the contents of the\ncollection.\n\n```\nlet vec = vec![1, 2, 3, 4];\nfor x in vec.iter() {\n   println!(\"vec contained {}\", x);\n}\n```\n\n`iter_mut` provides an iterator of *mutable* references in the same order as\n`iter`. This is great for mutating all the contents of the collection.\n\n```\nlet mut vec = vec![1, 2, 3, 4];\nfor x in vec.iter_mut() {\n   *x += 1;\n}\n```\n\n`into_iter` transforms the actual collection into an iterator over its\ncontents by-value. This is great when the collection itself is no longer\nneeded, and the values are needed elsewhere. Using `extend` with `into_iter`\nis the main way that contents of one collection are moved into another.\n`extend` automatically calls `into_iter`, and takes any `T: `[`IntoIterator`].\nCalling `collect` on an iterator itself is also a great way to convert one\ncollection into another. Both of these methods should internally use the\ncapacity management tools discussed in the previous section to do this as\nefficiently as possible.\n\n```\nlet mut vec1 = vec![1, 2, 3, 4];\nlet vec2 = vec![10, 20, 30, 40];\nvec1.extend(vec2);\n```\n\n```\nuse std::collections::VecDeque;\n\nlet vec = vec![1, 2, 3, 4];\nlet buf: VecDeque<_> = vec.into_iter().collect();\n```\n\nIterators also provide a series of *adapter* methods for performing common\nthreads to sequences. Among the adapters are functional favorites like `map`,\n`fold`, `skip` and `take`. Of particular interest to collections is the\n`rev` adapter, that reverses any iterator that supports this operation. Most\ncollections provide reversible iterators as the way to iterate over them in\nreverse order.\n\n```\nlet vec = vec![1, 2, 3, 4];\nfor x in vec.iter().rev() {\n   println!(\"vec contained {}\", x);\n}\n```\n\nSeveral other collection methods also return iterators to yield a sequence\nof results but avoid allocating an entire collection to store the result in.\nThis provides maximum flexibility as `collect` or `extend` can be called to\n\"pipe\" the sequence into any collection if desired. Otherwise, the sequence\ncan be looped over with a `for` loop. The iterator can also be discarded\nafter partial use, preventing the computation of the unused items.\n\n## Entries\n\nThe `entry` API is intended to provide an efficient mechanism for\nmanipulating the contents of a map conditionally on the presence of a key or\nnot. The primary motivating use case for this is to provide efficient\naccumulator maps. For instance, if one wishes to maintain a count of the\nnumber of times each key has been seen, they will have to perform some\nconditional logic on whether this is the first time the key has been seen or\nnot. Normally, this would require a `find` followed by an `insert`,\neffectively duplicating the search effort on each insertion.\n\nWhen a user calls `map.entry(&key)`, the map will search for the key and\nthen yield a variant of the `Entry` enum.\n\nIf a `Vacant(entry)` is yielded, then the key *was not* found. In this case\nthe only valid operation is to `insert` a value into the entry. When this is\ndone, the vacant entry is consumed and converted into a mutable reference to\nthe value that was inserted. This allows for further manipulation of the\nvalue beyond the lifetime of the search itself. This is useful if complex\nlogic needs to be performed on the value regardless of whether the value was\njust inserted.\n\nIf an `Occupied(entry)` is yielded, then the key *was* found. In this case,\nthe user has several options: they can `get`, `insert` or `remove` the\nvalue of the occupied entry. Additionally, they can convert the occupied\nentry into a mutable reference to its value, providing symmetry to the\nvacant `insert` case.\n\n### Examples\n\nHere are the two primary ways in which `entry` is used. First, a simple\nexample where the logic performed on the values is trivial.\n\n#### Counting the number of times each character in a string occurs\n\n```\nuse std::collections::btree_map::BTreeMap;\n\nlet mut count = BTreeMap::new();\nlet message = \"she sells sea shells by the sea shore\";\n\nfor c in message.chars() {\n    *count.entry(c).or_insert(0) += 1;\n}\n\nassert_eq!(count.get(&\'s\'), Some(&8));\n\nprintln!(\"Number of occurrences of each character\");\nfor (char, count) in &count {\n    println!(\"{}: {}\", char, count);\n}\n```\n\nWhen the logic to be performed on the value is more complex, we may simply\nuse the `entry` API to ensure that the value is initialized and perform the\nlogic afterwards.\n\n#### Tracking the inebriation of customers at a bar\n\n```\nuse std::collections::btree_map::BTreeMap;\n\n// A client of the bar. They have a blood alcohol level.\nstruct Person { blood_alcohol: f32 }\n\n// All the orders made to the bar, by client id.\nlet orders = vec![1,2,1,2,3,4,1,2,2,3,4,1,1,1];\n\n// Our clients.\nlet mut blood_alcohol = BTreeMap::new();\n\nfor id in orders {\n    // If this is the first time we\'ve seen this customer, initialize them\n    // with no blood alcohol. Otherwise, just retrieve them.\n    let person = blood_alcohol.entry(id).or_insert(Person { blood_alcohol: 0.0 });\n\n    // Reduce their blood alcohol level. It takes time to order and drink a beer!\n    person.blood_alcohol *= 0.9;\n\n    // Check if they\'re sober enough to have another beer.\n    if person.blood_alcohol > 0.3 {\n        // Too drunk... for now.\n        println!(\"Sorry {}, I have to cut you off\", id);\n    } else {\n        // Have another!\n        person.blood_alcohol += 0.1;\n    }\n}\n```\n\n# Insert and complex keys\n\nIf we have a more complex key, calls to `insert` will\nnot update the value of the key. For example:\n\n```\nuse std::cmp::Ordering;\nuse std::collections::BTreeMap;\nuse std::hash::{Hash, Hasher};\n\n#[derive(Debug)]\nstruct Foo {\n    a: u32,\n    b: &\'static str,\n}\n\n// we will compare `Foo`s by their `a` value only.\nimpl PartialEq for Foo {\n    fn eq(&self, other: &Self) -> bool { self.a == other.a }\n}\n\nimpl Eq for Foo {}\n\n// we will hash `Foo`s by their `a` value only.\nimpl Hash for Foo {\n    fn hash<H: Hasher>(&self, h: &mut H) { self.a.hash(h); }\n}\n\nimpl PartialOrd for Foo {\n    fn partial_cmp(&self, other: &Self) -> Option<Ordering> { self.a.partial_cmp(&other.a) }\n}\n\nimpl Ord for Foo {\n    fn cmp(&self, other: &Self) -> Ordering { self.a.cmp(&other.a) }\n}\n\nlet mut map = BTreeMap::new();\nmap.insert(Foo { a: 1, b: \"baz\" }, 99);\n\n// We already have a Foo with an a of 1, so this will be updating the value.\nmap.insert(Foo { a: 1, b: \"xyz\" }, 100);\n\n// The value has been updated...\nassert_eq!(map.values().next().unwrap(), &100);\n\n// ...but the key hasn\'t changed. b is still \"baz\", not \"xyz\".\nassert_eq!(map.keys().next().unwrap().b, \"baz\");\n```\n\n[`Vec`]: ../../std/vec/struct.Vec.html\n[`HashMap`]: ../../std/collections/struct.HashMap.html\n[`VecDeque`]: ../../std/collections/struct.VecDeque.html\n[`LinkedList`]: ../../std/collections/struct.LinkedList.html\n[`BTreeMap`]: ../../std/collections/struct.BTreeMap.html\n[`HashSet`]: ../../std/collections/struct.HashSet.html\n[`BTreeSet`]: ../../std/collections/struct.BTreeSet.html\n[`BinaryHeap`]: ../../std/collections/struct.BinaryHeap.html\n[`IntoIterator`]: ../../std/iter/trait.IntoIterator.html":
=> /html[0]/body[1]/table[27]/thead[0]/tr[0]/th[1] => [Texts differ]: expected "get(i)", found " get(i)         "
=> /html[0]/body[1]/table[27]/thead[0]/tr[0]/th[2] => [Texts differ]: expected "insert(i)", found " insert(i)       "
=> /html[0]/body[1]/table[27]/thead[0]/tr[0]/th[3] => [Texts differ]: expected "remove(i)", found " remove(i)      "
=> /html[0]/body[1]/table[27]/thead[0]/tr[0]/th[4] => [Texts differ]: expected "append", found " append "
=> /html[0]/body[1]/table[27]/thead[0]/tr[0]/th[5] => [Texts differ]: expected "split_off(i)", found " split_off(i)   "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[0]/td[1] => [Texts differ]: expected "O(1)", found " O(1)           "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[0]/td[2] => [Texts differ]: expected "O(n-i)*", found " O(n-i)*         "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[0]/td[3] => [Texts differ]: expected "O(n-i)", found " O(n-i)         "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[0]/td[4] => [Texts differ]: expected "O(m)*", found " O(m)*  "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[0]/td[5] => [Texts differ]: expected "O(n-i)", found " O(n-i)         "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[1]/td[1] => [Texts differ]: expected "O(1)", found " O(1)           "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[1]/td[2] => [Texts differ]: expected "O(min(i, n-i))*", found " O(min(i, n-i))* "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[1]/td[3] => [Texts differ]: expected "O(min(i, n-i))", found " O(min(i, n-i)) "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[1]/td[4] => [Texts differ]: expected "O(m)*", found " O(m)*  "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[1]/td[5] => [Texts differ]: expected "O(min(i, n-i))", found " O(min(i, n-i)) "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[2]/td[1] => [Texts differ]: expected "O(min(i, n-i))", found " O(min(i, n-i)) "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[2]/td[2] => [Texts differ]: expected "O(min(i, n-i))", found " O(min(i, n-i))  "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[2]/td[3] => [Texts differ]: expected "O(min(i, n-i))", found " O(min(i, n-i)) "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[2]/td[4] => [Texts differ]: expected "O(1)", found " O(1)   "
=> /html[0]/body[1]/table[27]/tbody[1]/tr[2]/td[5] => [Texts differ]: expected "O(min(i, n-i))", found " O(min(i, n-i)) "
=> /html[0]/body[1]/table[31]/thead[0]/tr[0]/th[1] => [Texts differ]: expected "get", found " get       "
=> /html[0]/body[1]/table[31]/thead[0]/tr[0]/th[2] => [Texts differ]: expected "insert", found " insert   "
=> /html[0]/body[1]/table[31]/thead[0]/tr[0]/th[3] => [Texts differ]: expected "remove", found " remove   "
=> /html[0]/body[1]/table[31]/thead[0]/tr[0]/th[4] => [Texts differ]: expected "predecessor", found " predecessor "
=> /html[0]/body[1]/table[31]/thead[0]/tr[0]/th[5] => [Texts differ]: expected "append", found " append "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[0]/td[1] => [Texts differ]: expected "O(1)~", found " O(1)~     "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[0]/td[2] => [Texts differ]: expected "O(1)~*", found " O(1)~*   "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[0]/td[3] => [Texts differ]: expected "O(1)~", found " O(1)~    "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[0]/td[4] => [Texts differ]: expected "N/A", found " N/A         "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[0]/td[5] => [Texts differ]: expected "N/A", found " N/A    "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[1]/td[1] => [Texts differ]: expected "O(log n)", found " O(log n)  "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[1]/td[2] => [Texts differ]: expected "O(log n)", found " O(log n) "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[1]/td[3] => [Texts differ]: expected "O(log n)", found " O(log n) "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[1]/td[4] => [Texts differ]: expected "O(log n)", found " O(log n)    "
=> /html[0]/body[1]/table[31]/tbody[1]/tr[1]/td[5] => [Texts differ]: expected "O(n+m)", found " O(n+m) "
Differences spotted in "Checks if the value is an ASCII punctuation character:\nU+0021 ... U+002F `! \" # $ % & \' ( ) * + , - . /`\nU+003A ... U+0040 `: ; < = > ? @`\nU+005B ... U+0060 `[ \\\\ ] ^ _ \\``\nU+007B ... U+007E `{ | } ~`\nFor strings, true if all characters in the string are\nASCII punctuation.\n\n# Examples\n\n```\n#![feature(ascii_ctype)]\n# #![allow(non_snake_case)]\nuse std::ascii::AsciiExt;\nlet A = \'A\';\nlet G = \'G\';\nlet a = \'a\';\nlet g = \'g\';\nlet zero = \'0\';\nlet percent = \'%\';\nlet space = \' \';\nlet lf = \'\\n\';\nlet esc = \'\\u{001b}\';\n\nassert!(!A.is_ascii_punctuation());\nassert!(!G.is_ascii_punctuation());\nassert!(!a.is_ascii_punctuation());\nassert!(!g.is_ascii_punctuation());\nassert!(!zero.is_ascii_punctuation());\nassert!(percent.is_ascii_punctuation());\nassert!(!space.is_ascii_punctuation());\nassert!(!lf.is_ascii_punctuation());\nassert!(!esc.is_ascii_punctuation());\n```":
=> /html[0]/body[1]/p[0]/code[2] => [Texts differ]: expected "[ \\\\ ] ^ _ \\", found "[ \\\\ ] ^ _ \\`` U+007B ... U+007E"
=> /html[0]/body[1]/p[0] => [Types differ]: expected "code", found ""
=> /html[0]/body[1]/p[0] => [One element is missing]: expected ""
Differences spotted in "Utilities for formatting and printing `String`s\n\nThis module contains the runtime support for the [`format!`] syntax extension.\nThis macro is implemented in the compiler to emit calls to this module in\norder to format arguments at runtime into strings.\n\n# Usage\n\nThe [`format!`] macro is intended to be familiar to those coming from C\'s\n`printf`/`fprintf` functions or Python\'s `str.format` function.\n\nSome examples of the [`format!`] extension are:\n\n```\nformat!(\"Hello\");                 // => \"Hello\"\nformat!(\"Hello, {}!\", \"world\");   // => \"Hello, world!\"\nformat!(\"The number is {}\", 1);   // => \"The number is 1\"\nformat!(\"{:?}\", (3, 4));          // => \"(3, 4)\"\nformat!(\"{value}\", value=4);      // => \"4\"\nformat!(\"{} {}\", 1, 2);           // => \"1 2\"\nformat!(\"{:04}\", 42);             // => \"0042\" with leading zeros\n```\n\nFrom these, you can see that the first argument is a format string. It is\nrequired by the compiler for this to be a string literal; it cannot be a\nvariable passed in (in order to perform validity checking). The compiler\nwill then parse the format string and determine if the list of arguments\nprovided is suitable to pass to this format string.\n\n## Positional parameters\n\nEach formatting argument is allowed to specify which value argument it\'s\nreferencing, and if omitted it is assumed to be \"the next argument\". For\nexample, the format string `{} {} {}` would take three parameters, and they\nwould be formatted in the same order as they\'re given. The format string\n`{2} {1} {0}`, however, would format arguments in reverse order.\n\nThings can get a little tricky once you start intermingling the two types of\npositional specifiers. The \"next argument\" specifier can be thought of as an\niterator over the argument. Each time a \"next argument\" specifier is seen,\nthe iterator advances. This leads to behavior like this:\n\n```\nformat!(\"{1} {} {0} {}\", 1, 2); // => \"2 1 1 2\"\n```\n\nThe internal iterator over the argument has not been advanced by the time\nthe first `{}` is seen, so it prints the first argument. Then upon reaching\nthe second `{}`, the iterator has advanced forward to the second argument.\nEssentially, parameters which explicitly name their argument do not affect\nparameters which do not name an argument in terms of positional specifiers.\n\nA format string is required to use all of its arguments, otherwise it is a\ncompile-time error. You may refer to the same argument more than once in the\nformat string.\n\n## Named parameters\n\nRust itself does not have a Python-like equivalent of named parameters to a\nfunction, but the [`format!`] macro is a syntax extension which allows it to\nleverage named parameters. Named parameters are listed at the end of the\nargument list and have the syntax:\n\n```text\nidentifier \'=\' expression\n```\n\nFor example, the following [`format!`] expressions all use named argument:\n\n```\nformat!(\"{argument}\", argument = \"test\");   // => \"test\"\nformat!(\"{name} {}\", 1, name = 2);          // => \"2 1\"\nformat!(\"{a} {c} {b}\", a=\"a\", b=\'b\', c=3);  // => \"a 3 b\"\n```\n\nIt is not valid to put positional parameters (those without names) after\narguments which have names. Like with positional parameters, it is not\nvalid to provide named parameters that are unused by the format string.\n\n## Argument types\n\nEach argument\'s type is dictated by the format string.\nThere are various parameters which require a particular type, however.\nAn example is the `{:.*}` syntax, which sets the number of decimal places\nin floating-point types:\n\n```\nlet formatted_number = format!(\"{:.*}\", 2, 1.234567);\n\nassert_eq!(\"1.23\", formatted_number)\n```\n\nIf this syntax is used, then the number of characters to print precedes the\nactual object being formatted, and the number of characters must have the\ntype [`usize`].\n\n## Formatting traits\n\nWhen requesting that an argument be formatted with a particular type, you\nare actually requesting that an argument ascribes to a particular trait.\nThis allows multiple actual types to be formatted via `{:x}` (like [`i8`] as\nwell as [`isize`]).  The current mapping of types to traits is:\n\n* *nothing* ⇒ [`Display`]\n* `?` ⇒ [`Debug`]\n* `o` ⇒ [`Octal`](trait.Octal.html)\n* `x` ⇒ [`LowerHex`](trait.LowerHex.html)\n* `X` ⇒ [`UpperHex`](trait.UpperHex.html)\n* `p` ⇒ [`Pointer`](trait.Pointer.html)\n* `b` ⇒ [`Binary`]\n* `e` ⇒ [`LowerExp`](trait.LowerExp.html)\n* `E` ⇒ [`UpperExp`](trait.UpperExp.html)\n\nWhat this means is that any type of argument which implements the\n[`fmt::Binary`][`Binary`] trait can then be formatted with `{:b}`. Implementations\nare provided for these traits for a number of primitive types by the\nstandard library as well. If no format is specified (as in `{}` or `{:6}`),\nthen the format trait used is the [`Display`] trait.\n\nWhen implementing a format trait for your own type, you will have to\nimplement a method of the signature:\n\n```\n# #![allow(dead_code)]\n# use std::fmt;\n# struct Foo; // our custom type\n# impl fmt::Display for Foo {\nfn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n# write!(f, \"testing, testing\")\n# } }\n```\n\nYour type will be passed as `self` by-reference, and then the function\nshould emit output into the `f.buf` stream. It is up to each format trait\nimplementation to correctly adhere to the requested formatting parameters.\nThe values of these parameters will be listed in the fields of the\n[`Formatter`] struct. In order to help with this, the [`Formatter`] struct also\nprovides some helper methods.\n\nAdditionally, the return value of this function is [`fmt::Result`] which is a\ntype alias of [`Result`]`<(), `[`std::fmt::Error`]`>`. Formatting implementations\nshould ensure that they propagate errors from the [`Formatter`][`Formatter`] (e.g., when\ncalling [`write!`]) however, they should never return errors spuriously. That\nis, a formatting implementation must and may only return an error if the\npassed-in [`Formatter`] returns an error. This is because, contrary to what\nthe function signature might suggest, string formatting is an infallible\noperation. This function only returns a result because writing to the\nunderlying stream might fail and it must provide a way to propagate the fact\nthat an error has occurred back up the stack.\n\nAn example of implementing the formatting traits would look\nlike:\n\n```\nuse std::fmt;\n\n#[derive(Debug)]\nstruct Vector2D {\n    x: isize,\n    y: isize,\n}\n\nimpl fmt::Display for Vector2D {\n    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n        // The `f` value implements the `Write` trait, which is what the\n        // write! macro is expecting. Note that this formatting ignores the\n        // various flags provided to format strings.\n        write!(f, \"({}, {})\", self.x, self.y)\n    }\n}\n\n// Different traits allow different forms of output of a type. The meaning\n// of this format is to print the magnitude of a vector.\nimpl fmt::Binary for Vector2D {\n    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {\n        let magnitude = (self.x * self.x + self.y * self.y) as f64;\n        let magnitude = magnitude.sqrt();\n\n        // Respect the formatting flags by using the helper method\n        // `pad_integral` on the Formatter object. See the method\n        // documentation for details, and the function `pad` can be used\n        // to pad strings.\n        let decimals = f.precision().unwrap_or(3);\n        let string = format!(\"{:.*}\", decimals, magnitude);\n        f.pad_integral(true, \"\", &string)\n    }\n}\n\nfn main() {\n    let myvector = Vector2D { x: 3, y: 4 };\n\n    println!(\"{}\", myvector);       // => \"(3, 4)\"\n    println!(\"{:?}\", myvector);     // => \"Vector2D {x: 3, y:4}\"\n    println!(\"{:10.3b}\", myvector); // => \"     5.000\"\n}\n```\n\n### `fmt::Display` vs `fmt::Debug`\n\nThese two formatting traits have distinct purposes:\n\n- [`fmt::Display`][`Display`] implementations assert that the type can be faithfully\n  represented as a UTF-8 string at all times. It is **not** expected that\n  all types implement the [`Display`] trait.\n- [`fmt::Debug`][`Debug`] implementations should be implemented for **all** public types.\n  Output will typically represent the internal state as faithfully as possible.\n  The purpose of the [`Debug`] trait is to facilitate debugging Rust code. In\n  most cases, using `#[derive(Debug)]` is sufficient and recommended.\n\nSome examples of the output from both traits:\n\n```\nassert_eq!(format!(\"{} {:?}\", 3, 4), \"3 4\");\nassert_eq!(format!(\"{} {:?}\", \'a\', \'b\'), \"a \'b\'\");\nassert_eq!(format!(\"{} {:?}\", \"foo\\n\", \"bar\\n\"), \"foo\\n \\\"bar\\\\n\\\"\");\n```\n\n## Related macros\n\nThere are a number of related macros in the [`format!`] family. The ones that\nare currently implemented are:\n\n```ignore (only-for-syntax-highlight)\nformat!      // described above\nwrite!       // first argument is a &mut io::Write, the destination\nwriteln!     // same as write but appends a newline\nprint!       // the format string is printed to the standard output\nprintln!     // same as print but appends a newline\nformat_args! // described below.\n```\n\n### `write!`\n\nThis and [`writeln!`] are two macros which are used to emit the format string\nto a specified stream. This is used to prevent intermediate allocations of\nformat strings and instead directly write the output. Under the hood, this\nfunction is actually invoking the [`write_fmt`] function defined on the\n[`std::io::Write`] trait. Example usage is:\n\n```\n# #![allow(unused_must_use)]\nuse std::io::Write;\nlet mut w = Vec::new();\nwrite!(&mut w, \"Hello {}!\", \"world\");\n```\n\n### `print!`\n\nThis and [`println!`] emit their output to stdout. Similarly to the [`write!`]\nmacro, the goal of these macros is to avoid intermediate allocations when\nprinting output. Example usage is:\n\n```\nprint!(\"Hello {}!\", \"world\");\nprintln!(\"I have a newline {}\", \"character at the end\");\n```\n\n### `format_args!`\n\nThis is a curious macro which is used to safely pass around\nan opaque object describing the format string. This object\ndoes not require any heap allocations to create, and it only\nreferences information on the stack. Under the hood, all of\nthe related macros are implemented in terms of this. First\noff, some example usage is:\n\n```\n# #![allow(unused_must_use)]\nuse std::fmt;\nuse std::io::{self, Write};\n\nlet mut some_writer = io::stdout();\nwrite!(&mut some_writer, \"{}\", format_args!(\"print with a {}\", \"macro\"));\n\nfn my_fmt_fn(args: fmt::Arguments) {\n    write!(&mut io::stdout(), \"{}\", args);\n}\nmy_fmt_fn(format_args!(\", or a {} too\", \"function\"));\n```\n\nThe result of the [`format_args!`] macro is a value of type [`fmt::Arguments`].\nThis structure can then be passed to the [`write`] and [`format`] functions\ninside this module in order to process the format string.\nThe goal of this macro is to even further prevent intermediate allocations\nwhen dealing formatting strings.\n\nFor example, a logging library could use the standard formatting syntax, but\nit would internally pass around this structure until it has been determined\nwhere output should go to.\n\n# Syntax\n\nThe syntax for the formatting language used is drawn from other languages,\nso it should not be too alien. Arguments are formatted with Python-like\nsyntax, meaning that arguments are surrounded by `{}` instead of the C-like\n`%`. The actual grammar for the formatting syntax is:\n\n```text\nformat_string := <text> [ maybe-format <text> ] *\nmaybe-format := \'{\' \'{\' | \'}\' \'}\' | <format>\nformat := \'{\' [ argument ] [ \':\' format_spec ] \'}\'\nargument := integer | identifier\n\nformat_spec := [[fill]align][sign][\'#\'][\'0\'][width][\'.\' precision][type]\nfill := character\nalign := \'<\' | \'^\' | \'>\'\nsign := \'+\' | \'-\'\nwidth := count\nprecision := count | \'*\'\ntype := identifier | \'\'\ncount := parameter | integer\nparameter := argument \'$\'\n```\n\n# Formatting Parameters\n\nEach argument being formatted can be transformed by a number of formatting\nparameters (corresponding to `format_spec` in the syntax above). These\nparameters affect the string representation of what\'s being formatted. This\nsyntax draws heavily from Python\'s, so it may seem a bit familiar.\n\n## Fill/Alignment\n\nThe fill character is provided normally in conjunction with the `width`\nparameter. This indicates that if the value being formatted is smaller than\n`width` some extra characters will be printed around it. The extra\ncharacters are specified by `fill`, and the alignment can be one of the\nfollowing options:\n\n* `<` - the argument is left-aligned in `width` columns\n* `^` - the argument is center-aligned in `width` columns\n* `>` - the argument is right-aligned in `width` columns\n\nNote that alignment may not be implemented by some types. A good way\nto ensure padding is applied is to format your input, then use this\nresulting string to pad your output.\n\n## Sign/`#`/`0`\n\nThese can all be interpreted as flags for a particular formatter.\n\n* `+` - This is intended for numeric types and indicates that the sign\n        should always be printed. Positive signs are never printed by\n        default, and the negative sign is only printed by default for the\n        `Signed` trait. This flag indicates that the correct sign (`+` or `-`)\n        should always be printed.\n* `-` - Currently not used\n* `#` - This flag is indicates that the \"alternate\" form of printing should\n        be used. The alternate forms are:\n    * `#?` - pretty-print the [`Debug`] formatting\n    * `#x` - precedes the argument with a `0x`\n    * `#X` - precedes the argument with a `0x`\n    * `#b` - precedes the argument with a `0b`\n    * `#o` - precedes the argument with a `0o`\n* `0` - This is used to indicate for integer formats that the padding should\n        both be done with a `0` character as well as be sign-aware. A format\n        like `{:08}` would yield `00000001` for the integer `1`, while the\n        same format would yield `-0000001` for the integer `-1`. Notice that\n        the negative version has one fewer zero than the positive version.\n        Note that padding zeroes are always placed after the sign (if any)\n        and before the digits. When used together with the `#` flag, a similar\n        rule applies: padding zeroes are inserted after the prefix but before\n        the digits.\n\n## Width\n\nThis is a parameter for the \"minimum width\" that the format should take up.\nIf the value\'s string does not fill up this many characters, then the\npadding specified by fill/alignment will be used to take up the required\nspace.\n\nThe default fill/alignment for non-numerics is a space and left-aligned. The\ndefaults for numeric formatters is also a space but with right-alignment. If\nthe `0` flag is specified for numerics, then the implicit fill character is\n`0`.\n\nThe value for the width can also be provided as a [`usize`] in the list of\nparameters by using the dollar syntax indicating that the second argument is\na [`usize`] specifying the width, for example:\n\n```\n// All of these print \"Hello x    !\"\nprintln!(\"Hello {:5}!\", \"x\");\nprintln!(\"Hello {:1$}!\", \"x\", 5);\nprintln!(\"Hello {1:0$}!\", 5, \"x\");\nprintln!(\"Hello {:width$}!\", \"x\", width = 5);\n```\n\nReferring to an argument with the dollar syntax does not affect the \"next\nargument\" counter, so it\'s usually a good idea to refer to arguments by\nposition, or use named arguments.\n\n## Precision\n\nFor non-numeric types, this can be considered a \"maximum width\". If the resulting string is\nlonger than this width, then it is truncated down to this many characters and that truncated\nvalue is emitted with proper `fill`, `alignment` and `width` if those parameters are set.\n\nFor integral types, this is ignored.\n\nFor floating-point types, this indicates how many digits after the decimal point should be\nprinted.\n\nThere are three possible ways to specify the desired `precision`:\n\n1. An integer `.N`:\n\n   the integer `N` itself is the precision.\n\n2. An integer or name followed by dollar sign `.N$`:\n\n   use format *argument* `N` (which must be a `usize`) as the precision.\n\n3. An asterisk `.*`:\n\n   `.*` means that this `{...}` is associated with *two* format inputs rather than one: the\n   first input holds the `usize` precision, and the second holds the value to print.  Note that\n   in this case, if one uses the format string `{<arg>:<spec>.*}`, then the `<arg>` part refers\n   to the *value* to print, and the `precision` must come in the input preceding `<arg>`.\n\nFor example, the following calls all print the same thing `Hello x is 0.01000`:\n\n```\n// Hello {arg 0 (\"x\")} is {arg 1 (0.01) with precision specified inline (5)}\nprintln!(\"Hello {0} is {1:.5}\", \"x\", 0.01);\n\n// Hello {arg 1 (\"x\")} is {arg 2 (0.01) with precision specified in arg 0 (5)}\nprintln!(\"Hello {1} is {2:.0$}\", 5, \"x\", 0.01);\n\n// Hello {arg 0 (\"x\")} is {arg 2 (0.01) with precision specified in arg 1 (5)}\nprintln!(\"Hello {0} is {2:.1$}\", \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {second of next two args (0.01) with precision\n//                          specified in first of next two args (5)}\nprintln!(\"Hello {} is {:.*}\",    \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {arg 2 (0.01) with precision\n//                          specified in its predecessor (5)}\nprintln!(\"Hello {} is {2:.*}\",   \"x\", 5, 0.01);\n\n// Hello {next arg (\"x\")} is {arg \"number\" (0.01) with precision specified\n//                          in arg \"prec\" (5)}\nprintln!(\"Hello {} is {number:.prec$}\", \"x\", prec = 5, number = 0.01);\n```\n\nWhile these:\n\n```\nprintln!(\"{}, `{name:.*}` has 3 fractional digits\", \"Hello\", 3, name=1234.56);\nprintln!(\"{}, `{name:.*}` has 3 characters\", \"Hello\", 3, name=\"1234.56\");\nprintln!(\"{}, `{name:>8.*}` has 3 right-aligned characters\", \"Hello\", 3, name=\"1234.56\");\n```\n\nprint two significantly different things:\n\n```text\nHello, `1234.560` has 3 fractional digits\nHello, `123` has 3 characters\nHello, `     123` has 3 right-aligned characters\n```\n\n# Escaping\n\nThe literal characters `{` and `}` may be included in a string by preceding\nthem with the same character. For example, the `{` character is escaped with\n`{{` and the `}` character is escaped with `}}`.\n\n[`format!`]: ../../macro.format.html\n[`usize`]: ../../std/primitive.usize.html\n[`isize`]: ../../std/primitive.isize.html\n[`i8`]: ../../std/primitive.i8.html\n[`Display`]: trait.Display.html\n[`Binary`]: trait.Binary.html\n[`fmt::Result`]: type.Result.html\n[`Result`]: ../../std/result/enum.Result.html\n[`std::fmt::Error`]: struct.Error.html\n[`Formatter`]: struct.Formatter.html\n[`write!`]: ../../std/macro.write.html\n[`Debug`]: trait.Debug.html\n[`format!`]: ../../std/macro.format.html\n[`writeln!`]: ../../std/macro.writeln.html\n[`write_fmt`]: ../../std/io/trait.Write.html#method.write_fmt\n[`std::io::Write`]: ../../std/io/trait.Write.html\n[`println!`]: ../../std/macro.println.html\n[`write!`]: ../../std/macro.write.html\n[`format_args!`]: ../../std/macro.format_args.html\n[`fmt::Arguments`]: struct.Arguments.html\n[`write`]: fn.write.html\n[`format`]: fn.format.html":
=> /html[0]/body[1]/ul[63]/li[0] => [Texts differ]: expected " - This is intended for numeric types and indicates that the sign\n    should always be printed. Positive signs are never printed by\n    default, and the negative sign is only printed by default for the\n    ", found " - This is intended for numeric types and indicates that the sign\nshould always be printed. Positive signs are never printed by\ndefault, and the negative sign is only printed by default for the\n"
=> /html[0]/body[1]/ul[63]/li[0] => [Texts differ]: expected ")\n    should always be printed.", found ")\nshould always be printed."
=> /html[0]/body[1]/ul[63]/li[2] => [Texts differ]: expected " - This flag is indicates that the \"alternate\" form of printing should\n    be used. The alternate forms are:\n\n", found " - This flag is indicates that the \"alternate\" form of printing should\nbe used. The alternate forms are:\n"
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " - This is used to indicate for integer formats that the padding should\n    both be done with a ", found " - This is used to indicate for integer formats that the padding should\nboth be done with a "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " character as well as be sign-aware. A format\n    like ", found " character as well as be sign-aware. A format\nlike "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected ", while the\n    same format would yield ", found ", while the\nsame format would yield "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected ". Notice that\n    the negative version has one fewer zero than the positive version.\n    Note that padding zeroes are always placed after the sign (if any)\n    and before the digits. When used together with the ", found ". Notice that\nthe negative version has one fewer zero than the positive version.\nNote that padding zeroes are always placed after the sign (if any)\nand before the digits. When used together with the "
=> /html[0]/body[1]/ul[63]/li[3] => [Texts differ]: expected " flag, a similar\n    rule applies: padding zeroes are inserted after the prefix but before\n    the digits.", found " flag, a similar\nrule applies: padding zeroes are inserted after the prefix but before\nthe digits."
Differences spotted in "This function takes a string slice and emits it to the internal buffer\nafter applying the relevant formatting flags specified. The flags\nrecognized for generic strings are:\n\n* width - the minimum width of what to emit\n* fill/align - what to emit and where to emit it if the string\n               provided needs to be padded\n* precision - the maximum length to emit, the string is truncated if it\n              is longer than this length\n\nNotably this function ignores the `flag` parameters.":
=> /html[0]/body[1]/ul[1]/li[1] => [Texts differ]: expected "fill/align - what to emit and where to emit it if the string\n           provided needs to be padded", found "fill/align - what to emit and where to emit it if the string\nprovided needs to be padded"
=> /html[0]/body[1]/ul[1]/li[2] => [Texts differ]: expected "precision - the maximum length to emit, the string is truncated if it\n          is longer than this length", found "precision - the maximum length to emit, the string is truncated if it\nis longer than this length"
Differences spotted in "Types that can be \"unsized\" to a dynamically-sized type.\n\nFor example, the sized array type `[i8; 2]` implements `Unsize<[i8]>` and\n`Unsize<fmt::Debug>`.\n\nAll implementations of `Unsize` are provided automatically by the compiler.\n\n`Unsize` is implemented for:\n\n- `[T; N]` is `Unsize<[T]>`\n- `T` is `Unsize<Trait>` when `T: Trait`\n- `Foo<..., T, ...>` is `Unsize<Foo<..., U, ...>>` if:\n  - `T: Unsize<U>`\n  - Foo is a struct\n  - Only the last field of `Foo` has a type involving `T`\n  - `T` is not part of the type of any other fields\n  - `Bar<T>: Unsize<Bar<U>>`, if the last field of `Foo` has type `Bar<T>`\n\n`Unsize` is used along with [`ops::CoerceUnsized`][coerceunsized] to allow\n\"user-defined\" containers such as [`rc::Rc`][rc] to contain dynamically-sized\ntypes. See the [DST coercion RFC][RFC982] and [the nomicon entry on coercion][nomicon-coerce]\nfor more details.\n\n[coerceunsized]: ../ops/trait.CoerceUnsized.html\n[rc]: ../../std/rc/struct.Rc.html\n[RFC982]: https://github.com/rust-lang/rfcs/blob/master/text/0982-dst-coercion.md\n[nomicon-coerce]: ../../nomicon/coercions.html":
=> /html[0]/body[1]/ul[4]/li[2] => [Texts differ]: expected " if:\n\n", found " if:\n"
Differences spotted in "An iterator adaptor that applies a function, producing a single, final value.\n\n`fold()` takes two arguments: an initial value, and a closure with two\narguments: an \'accumulator\', and an element. The closure returns the value that\nthe accumulator should have for the next iteration.\n\nThe initial value is the value the accumulator will have on the first\ncall.\n\nAfter applying this closure to every element of the iterator, `fold()`\nreturns the accumulator.\n\nThis operation is sometimes called \'reduce\' or \'inject\'.\n\nFolding is useful whenever you have a collection of something, and want\nto produce a single value from it.\n\n# Examples\n\nBasic usage:\n\n```\nlet a = [1, 2, 3];\n\n// the sum of all of the elements of a\nlet sum = a.iter()\n           .fold(0, |acc, &x| acc + x);\n\nassert_eq!(sum, 6);\n```\n\nLet\'s walk through each step of the iteration here:\n\n| element | acc | x | result |\n|---------|-----|---|--------|\n|         | 0   |   |        |\n| 1       | 0   | 1 | 1      |\n| 2       | 1   | 2 | 3      |\n| 3       | 3   | 3 | 6      |\n\nAnd so, our final result, `6`.\n\nIt\'s common for people who haven\'t used iterators a lot to\nuse a `for` loop with a list of things to build up a result. Those\ncan be turned into `fold()`s:\n\n[`for`]: ../../book/first-edition/loops.html#for\n\n```\nlet numbers = [1, 2, 3, 4, 5];\n\nlet mut result = 0;\n\n// for loop:\nfor i in &numbers {\n    result = result + i;\n}\n\n// fold:\nlet result2 = numbers.iter().fold(0, |acc, &x| acc + x);\n\n// they\'re the same\nassert_eq!(result, result2);\n```":
=> /html[0]/body[1]/table[10]/thead[0]/tr[0]/th[0] => [Texts differ]: expected "element", found " element "
=> /html[0]/body[1]/table[10]/thead[0]/tr[0]/th[1] => [Texts differ]: expected "acc", found " acc "
=> /html[0]/body[1]/table[10]/thead[0]/tr[0]/th[2] => [Texts differ]: expected "x", found " x "
=> /html[0]/body[1]/table[10]/thead[0]/tr[0]/th[3] => [Texts differ]: expected "result", found " result "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[0]/td[1] => [Texts differ]: expected "0", found " 0   "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[1]/td[0] => [Texts differ]: expected "1", found " 1       "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[1]/td[1] => [Texts differ]: expected "0", found " 0   "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[1]/td[2] => [Texts differ]: expected "1", found " 1 "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[1]/td[3] => [Texts differ]: expected "1", found " 1      "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[2]/td[0] => [Texts differ]: expected "2", found " 2       "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[2]/td[1] => [Texts differ]: expected "1", found " 1   "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[2]/td[2] => [Texts differ]: expected "2", found " 2 "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[2]/td[3] => [Texts differ]: expected "3", found " 3      "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[3]/td[0] => [Texts differ]: expected "3", found " 3       "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[3]/td[1] => [Texts differ]: expected "3", found " 3   "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[3]/td[2] => [Texts differ]: expected "3", found " 3 "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[3]/td[3] => [Texts differ]: expected "6", found " 6      "
Differences spotted in "An implementation of SipHash 2-4.\n\nSee: https://131002.net/siphash/":
=> /html[0]/body[1]/p[1] => [Texts differ]: expected "See: ", found "See: https://131002.net/siphash/"
=> /html[0]/body[1]/p[1] => [One element is missing]: expected "a"
Differences spotted in "An implementation of SipHash 2-4.\n\nSee: https://131002.net/siphash/\n\nSipHash is a general-purpose hashing function: it runs at a good\nspeed (competitive with Spooky and City) and permits strong _keyed_\nhashing. This lets you key your hashtables from a strong RNG, such as\n[`rand::os::OsRng`](https://doc.rust-lang.org/rand/rand/os/struct.OsRng.html).\n\nAlthough the SipHash algorithm is considered to be generally strong,\nit is not intended for cryptographic purposes. As such, all\ncryptographic uses of this implementation are _strongly discouraged_.":
=> /html[0]/body[1]/p[1] => [Texts differ]: expected "See: ", found "See: https://131002.net/siphash/"
=> /html[0]/body[1]/p[1] => [One element is missing]: expected "a"
Differences spotted in "An implementation of SipHash 1-3.\n\nThis is currently the default hashing function used by standard library\n(eg. `collections::HashMap` uses it by default).\n\nSee: https://131002.net/siphash/":
=> /html[0]/body[1]/p[2] => [Texts differ]: expected "See: ", found "See: https://131002.net/siphash/"
=> /html[0]/body[1]/p[2] => [One element is missing]: expected "a"
Differences spotted in "# The Rust Core Library\n\nThe Rust Core Library is the dependency-free[^free] foundation of [The\nRust Standard Library](../std/index.html). It is the portable glue\nbetween the language and its libraries, defining the intrinsic and\nprimitive building blocks of all Rust code. It links to no\nupstream libraries, no system libraries, and no libc.\n\n[^free]: Strictly speaking, there are some symbols which are needed but\n         they aren\'t always necessary.\n\nThe core library is *minimal*: it isn\'t even aware of heap allocation,\nnor does it provide concurrency or I/O. These things require\nplatform integration, and this library is platform-agnostic.\n\n# How to use the core library\n\nPlease note that all of these details are currently not considered stable.\n\nThis library is built on the assumption of a few existing symbols:\n\n* `memcpy`, `memcmp`, `memset` - These are core memory routines which are\n  often generated by LLVM. Additionally, this library can make explicit\n  calls to these functions. Their signatures are the same as found in C.\n  These functions are often provided by the system libc, but can also be\n  provided by the [rlibc crate](https://crates.io/crates/rlibc).\n\n* `rust_begin_panic` - This function takes four arguments, a\n  `fmt::Arguments`, a `&\'static str`, and two `u32`\'s. These four arguments\n  dictate the panic message, the file at which panic was invoked, and the\n  line and column inside the file. It is up to consumers of this core\n  library to define this panic function; it is only required to never\n  return. This requires a `lang` attribute named `panic_fmt`.\n\n* `rust_eh_personality` - is used by the failure mechanisms of the\n   compiler. This is often mapped to GCC\'s personality function, but crates\n   which do not trigger a panic can be assured that this function is never\n   called. The `lang` attribute is called `eh_personality`.":
=> /html[0]/body[1]/p[1]/sup[0] => [Attributes differ in "a"]: expected "{"rel": "footnote", "href": "#fn1"}", found "{"href": "#ref1"}"
=> /html[0]/body[1] => [Tags differ]: expected "p", found "div"
=> /html[0]/body[1] => [One element is missing]: expected "h1"
=> /html[0]/body[1] => [One element is missing]: expected "p"
=> /html[0]/body[1] => [One element is missing]: expected "p"
=> /html[0]/body[1] => [One element is missing]: expected "ul"
=> /html[0]/body[1] => [One element is missing]: expected "div"
Differences spotted in "This function takes a string slice and emits it to the internal buffer\nafter applying the relevant formatting flags specified. The flags\nrecognized for generic strings are:\n\n* width - the minimum width of what to emit\n* fill/align - what to emit and where to emit it if the string\n               provided needs to be padded\n* precision - the maximum length to emit, the string is truncated if it\n              is longer than this length\n\nNotably this function ignores the `flag` parameters.":
=> /html[0]/body[1]/ul[1]/li[1] => [Texts differ]: expected "fill/align - what to emit and where to emit it if the string\n           provided needs to be padded", found "fill/align - what to emit and where to emit it if the string\nprovided needs to be padded"
=> /html[0]/body[1]/ul[1]/li[2] => [Texts differ]: expected "precision - the maximum length to emit, the string is truncated if it\n          is longer than this length", found "precision - the maximum length to emit, the string is truncated if it\nis longer than this length"
Differences spotted in "An implementation of SipHash 2-4.\n\nSee: https://131002.net/siphash/":
=> /html[0]/body[1]/p[1] => [Texts differ]: expected "See: ", found "See: https://131002.net/siphash/"
=> /html[0]/body[1]/p[1] => [One element is missing]: expected "a"
Differences spotted in "An implementation of SipHash 1-3.\n\nThis is currently the default hashing function used by standard library\n(eg. `collections::HashMap` uses it by default).\n\nSee: https://131002.net/siphash/":
=> /html[0]/body[1]/p[2] => [Texts differ]: expected "See: ", found "See: https://131002.net/siphash/"
=> /html[0]/body[1]/p[2] => [One element is missing]: expected "a"
Differences spotted in "An implementation of SipHash 2-4.\n\nSee: https://131002.net/siphash/\n\nSipHash is a general-purpose hashing function: it runs at a good\nspeed (competitive with Spooky and City) and permits strong _keyed_\nhashing. This lets you key your hashtables from a strong RNG, such as\n[`rand::os::OsRng`](https://doc.rust-lang.org/rand/rand/os/struct.OsRng.html).\n\nAlthough the SipHash algorithm is considered to be generally strong,\nit is not intended for cryptographic purposes. As such, all\ncryptographic uses of this implementation are _strongly discouraged_.":
=> /html[0]/body[1]/p[1] => [Texts differ]: expected "See: ", found "See: https://131002.net/siphash/"
=> /html[0]/body[1]/p[1] => [One element is missing]: expected "a"
Differences spotted in "An iterator adaptor that applies a function, producing a single, final value.\n\n`fold()` takes two arguments: an initial value, and a closure with two\narguments: an \'accumulator\', and an element. The closure returns the value that\nthe accumulator should have for the next iteration.\n\nThe initial value is the value the accumulator will have on the first\ncall.\n\nAfter applying this closure to every element of the iterator, `fold()`\nreturns the accumulator.\n\nThis operation is sometimes called \'reduce\' or \'inject\'.\n\nFolding is useful whenever you have a collection of something, and want\nto produce a single value from it.\n\n# Examples\n\nBasic usage:\n\n```\nlet a = [1, 2, 3];\n\n// the sum of all of the elements of a\nlet sum = a.iter()\n           .fold(0, |acc, &x| acc + x);\n\nassert_eq!(sum, 6);\n```\n\nLet\'s walk through each step of the iteration here:\n\n| element | acc | x | result |\n|---------|-----|---|--------|\n|         | 0   |   |        |\n| 1       | 0   | 1 | 1      |\n| 2       | 1   | 2 | 3      |\n| 3       | 3   | 3 | 6      |\n\nAnd so, our final result, `6`.\n\nIt\'s common for people who haven\'t used iterators a lot to\nuse a `for` loop with a list of things to build up a result. Those\ncan be turned into `fold()`s:\n\n[`for`]: ../../book/first-edition/loops.html#for\n\n```\nlet numbers = [1, 2, 3, 4, 5];\n\nlet mut result = 0;\n\n// for loop:\nfor i in &numbers {\n    result = result + i;\n}\n\n// fold:\nlet result2 = numbers.iter().fold(0, |acc, &x| acc + x);\n\n// they\'re the same\nassert_eq!(result, result2);\n```":
=> /html[0]/body[1]/table[10]/thead[0]/tr[0]/th[0] => [Texts differ]: expected "element", found " element "
=> /html[0]/body[1]/table[10]/thead[0]/tr[0]/th[1] => [Texts differ]: expected "acc", found " acc "
=> /html[0]/body[1]/table[10]/thead[0]/tr[0]/th[2] => [Texts differ]: expected "x", found " x "
=> /html[0]/body[1]/table[10]/thead[0]/tr[0]/th[3] => [Texts differ]: expected "result", found " result "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[0]/td[1] => [Texts differ]: expected "0", found " 0   "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[1]/td[0] => [Texts differ]: expected "1", found " 1       "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[1]/td[1] => [Texts differ]: expected "0", found " 0   "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[1]/td[2] => [Texts differ]: expected "1", found " 1 "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[1]/td[3] => [Texts differ]: expected "1", found " 1      "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[2]/td[0] => [Texts differ]: expected "2", found " 2       "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[2]/td[1] => [Texts differ]: expected "1", found " 1   "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[2]/td[2] => [Texts differ]: expected "2", found " 2 "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[2]/td[3] => [Texts differ]: expected "3", found " 3      "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[3]/td[0] => [Texts differ]: expected "3", found " 3       "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[3]/td[1] => [Texts differ]: expected "3", found " 3   "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[3]/td[2] => [Texts differ]: expected "3", found " 3 "
=> /html[0]/body[1]/table[10]/tbody[1]/tr[3]/td[3] => [Texts differ]: expected "6", found " 6      "
Differences spotted in "Types that can be \"unsized\" to a dynamically-sized type.\n\nFor example, the sized array type `[i8; 2]` implements `Unsize<[i8]>` and\n`Unsize<fmt::Debug>`.\n\nAll implementations of `Unsize` are provided automatically by the compiler.\n\n`Unsize` is implemented for:\n\n- `[T; N]` is `Unsize<[T]>`\n- `T` is `Unsize<Trait>` when `T: Trait`\n- `Foo<..., T, ...>` is `Unsize<Foo<..., U, ...>>` if:\n  - `T: Unsize<U>`\n  - Foo is a struct\n  - Only the last field of `Foo` has a type involving `T`\n  - `T` is not part of the type of any other fields\n  - `Bar<T>: Unsize<Bar<U>>`, if the last field of `Foo` has type `Bar<T>`\n\n`Unsize` is used along with [`ops::CoerceUnsized`][coerceunsized] to allow\n\"user-defined\" containers such as [`rc::Rc`][rc] to contain dynamically-sized\ntypes. See the [DST coercion RFC][RFC982] and [the nomicon entry on coercion][nomicon-coerce]\nfor more details.\n\n[coerceunsized]: ../ops/trait.CoerceUnsized.html\n[rc]: ../../std/rc/struct.Rc.html\n[RFC982]: https://github.com/rust-lang/rfcs/blob/master/text/0982-dst-coercion.md\n[nomicon-coerce]: ../../nomicon/coercions.html":
=> /html[0]/body[1]/ul[4]/li[2] => [Texts differ]: expected " if:\n\n", found " if:\n"