Code change:
#[doc(keyword = "struct")] // <del> /// The `struct` keyword. </del> <ins> /// The keyword used to define structs. </ins> /// <del> /// The `struct` keyword is used to define a struct type. </del> <ins> /// Structs in Rust come in three flavours: Regular structs, tuple structs, /// and empty structs. </ins> /// <del> /// Example: </del> <ins> /// ```rust /// struct Regular { ///     field1: f32, ///     field2: String, ///     pub field3: bool /// } /// /// struct Tuple(u32, String); </ins> /// <ins> /// struct Empty; </ins> /// ``` <del> /// struct Foo { ///     field1: u32, ///     field2: String, </del> <ins> /// /// Regular structs are the most commonly used. Each field defined within them has a name and a /// type, and once defined can be accessed using `example_struct.field` syntax. The fields of a /// struct share its mutability, so `foo.bar = 2;` would only be valid if `foo` was mutable. Adding /// `pub` to a field makes it visible to code in other modules, as well as allowing it to be /// directly accessed and modified. /// /// Tuple structs are similar to regular structs, but its fields have no names. They are used like /// tuples, with deconstruction possible via `let TupleStruct(x, y) = foo;` syntax.  For accessing /// individual variables, the same syntax is used as with regular tuples, namely `foo.0`, `foo.1`, /// etc, starting at zero. /// /// Empty structs, or unit-like structs, are most commonly used as markers, for example /// [`PhantomData`]. Empty structs have a size of zero bytes, but unlike empty enums they can be /// instantiated, making them similar to the unit type `()`. Unit-like structs are useful when you /// need to implement a trait on something, but don't need to store any data inside it. /// /// # Instantiation /// /// Structs can be instantiated in a manner of different ways, each of which can be mixed and /// matched as needed. The most common way to make a new struct is via a constructor method such as /// `new()`, but when that isn't available (or you're writing the constructor itself), struct /// literal syntax is used: /// /// ```rust /// # struct Foo { field1: f32, field2: String, etc: bool } /// let example = Foo { ///     field1: 42.0, ///     field2: "blah".to_string(), ///     etc: true, /// }; /// ``` /// /// It's only possible to directly instantiate a struct using struct literal syntax when all of its /// fields are visible to you. /// /// There are a handful of shortcuts provided to make writing constructors more convenient, most /// common of which is the Field Init shorthand. When there is a variable and a field of the same /// name, the assignment can be simplified from `field: field` into simply `field`. The following /// example of a hypothetical constructor demonstrates this: /// /// ```rust /// struct User { ///     name: String, ///     admin: bool, </ins> /// } <ins> /// /// impl User { ///     pub fn new(name: String) -> Self { ///         Self { ///             name, ///             admin: false, ///         } ///     } /// } /// ``` /// /// Another shortcut for struct instantiation is available, used when you need to make a new /// struct that has the same values as most of a previous struct of the same type, called struct /// update syntax: /// /// ```rust /// # struct Foo { field1: String, field2: () } /// # let thing = Foo { field1: "".to_string(), field2: () }; /// let updated_thing = Foo { ///     field1: "a new value".to_string(), ///     ..thing /// }; </ins> /// ``` /// <del> /// There are different kinds of structs. For more information, take a look at the /// [Rust Book][book]. </del> <ins> /// Tuple structs are instantiated in the same way as tuples themselves, except with the struct's /// name as a prefix: `Foo(123, false, 0.1)`. /// /// Empty structs are instantiated with just their name, and don't need anything else. `let thing = /// EmptyStruct;` /// /// # Style conventions /// /// Structs are always written in CamelCase, with few exceptions. While the trailing comma on a /// struct's list of fields can be omitted, it's usually kept for convenience in adding and /// removing fields down the line. /// /// For more information on structs, take a look at the [Rust Book][book] or the /// [Reference][reference]. </ins> /// <ins> /// [`PhantomData`]: marker/struct.PhantomData.html </ins> /// [book]: https://doc.rust-lang.org/book/second-edition/ch05-01-defining-structs.html <ins> /// [reference]: https://doc.rust-lang.org/reference/items/structs.html </ins> mod struct_keyword { }

Related discussion:
text: Consider the following code (): It currently yields the following diagnostic messages: This line is what I object to: It has two problems: It uses the terminology when discussing building up an instance of the struct . It uses a tuple struct form in the example rewrite it provides; but our is a braced struct with named fields.
Is GitHub suffering from some kind of cache-consistency problem!? (I guess so: they're investigating service unavailability.) I apparently-successfully opened PR to fix this, but then it wasn't showing up in the and the pull/ URL was 404ing, so then I thought that it might not have actually gone through, so then I tried to resubmit, and then that failed with an "A pull request already exists" flash message, and then I wanted to try submitting under a different branch name, and/or rebased so as to have a different SHA (on the theory that maybe the problem had something to do with the fact that I was reusing the branch name from the my PR of last year in which the "variant of the expected type" message was introduced, even though it would be really surprising if a site as old and usually-stable as GitHub didn't already handle that case), but then the "Compare branches" pages aren't showing the open-pull-request form that they usually do. Typically I wouldn't even bother commenting about this kind of glitch (trusting that our friends at GitHub will sort it out any mere availability issue soon enough), but the fact that other PR pages are loading fine for me makes me wonder if there's some kind of bad state associated with in particular?!
Is GitHub suffering from some kind of cache-consistency problem!? (I guess so: they're investigating service unavailability.)