Fix grammar rules containing or pertaining to bounds

src/items/generics.md

@@ -7,7 +7,7 @@ GenericParams -> `<` ( GenericParam (`,` GenericParam)* `,`? )? `>`
 
 GenericParam -> OuterAttribute* ( LifetimeParam | TypeParam | ConstParam )
 
-LifetimeParam -> Lifetime ( `:` LifetimeBounds )?
+LifetimeParam -> Lifetime ( `:` LifetimeBounds? )?
 
 TypeParam -> IDENTIFIER ( `:` Bounds? )? ( `=` Type )?
 
@@ -234,7 +234,7 @@ WhereClauseItem ->
       LifetimeWhereClauseItem
     | TypeBoundWhereClauseItem
 
-LifetimeWhereClauseItem -> Lifetime `:` LifetimeBounds
+LifetimeWhereClauseItem -> Lifetime `:` LifetimeBounds?
 
 TypeBoundWhereClauseItem -> ForLifetimes? Type `:` Bounds?
 ```

src/items/type-aliases.md

@@ -4,7 +4,7 @@ r[items.type]
 r[items.type.syntax]
 ```grammar,items
 TypeAlias ->
-    `type` IDENTIFIER GenericParams? ( `:` Bounds )?
+    `type` IDENTIFIER GenericParams? ( `:` Bounds? )?
         WhereClause?
         ( `=` Type WhereClause?)? `;`
 ```

src/paths.md

@@ -74,7 +74,7 @@ GenericArgsBinding ->
     TypePathSegment `=` Type
 
 GenericArgsBounds ->
-    TypePathSegment `:` Bounds
+    TypePathSegment `:` Bounds?
 ```
 
 r[paths.expr.intro]

src/types/impl-trait.md

@@ -3,9 +3,9 @@ r[type.impl-trait]
 
 r[type.impl-trait.syntax]
 ```grammar,types
-ImplTraitType -> `impl` Bounds
+ImplTraitType -> `impl` Bounds?
 
-ImplTraitTypeOneBound -> `impl` TraitBound
+ImplTraitTypeOneBound -> `impl` TraitBound?
 ```
 
 r[type.impl-trait.intro]
@@ -23,6 +23,10 @@ fn foo(arg: impl Trait) {
 fn bar() -> impl Trait {
 }
 ```
+
+r[type.impl-trait.bounds]
+There must be at least one trait bound, no more than one `use<..>` bound, and no more than one opt-out bound (e.g., `?Sized`).
+
 r[type.impl-trait.param]
 ## Anonymous type parameters
 

src/types/trait-object.md

@@ -3,22 +3,22 @@ r[type.trait-object]
 
 r[type.trait-object.syntax]
 ```grammar,types
-TraitObjectType -> `dyn`? Bounds
+TraitObjectType -> Bounds[^bare-2021] | `dyn`[^dyn-2018] Bounds?
 
-TraitObjectTypeOneBound -> `dyn`? TraitBound
+TraitObjectTypeOneBound -> TraitBound[^bare-2021] | `dyn`[^dyn-2018] TraitBound?
 ```
 
+[^bare-2021]: See [type.trait-object.syntax-edition2021].
+[^dyn-2018]: See [type.trait-object.syntax-edition2018].
+
 r[type.trait-object.intro]
 A *trait object* is an opaque value of another type that implements a set of traits. The set of traits is made up of a [dyn compatible] *base trait* plus any number of [auto traits].
 
 r[type.trait-object.impls]
 Trait objects implement the base trait, its auto traits, and any [supertraits] of the base trait.
 
-r[type.trait-object.name]
-Trait objects are written as the keyword `dyn` followed by a set of trait bounds, but with the following restrictions on the trait bounds.
-
-r[type.trait-object.constraint]
-There may not be more than one non-auto trait, no more than one lifetime, and opt-out bounds (e.g. `?Sized`) are not allowed. Furthermore, paths to traits may be parenthesized.
+r[type.trait-object.bounds]
+There must be at least one trait bound, there may not be more than one non-auto trait, no more than one lifetime, and opt-out bounds (e.g., `?Sized`) and `use<..>` bounds are not allowed.
 
 For example, given a trait `Trait`, the following are all trait objects:
 
@@ -33,11 +33,13 @@ For example, given a trait `Trait`, the following are all trait objects:
 
 r[type.trait-object.syntax-edition2021]
 > [!EDITION-2021]
-> Before the 2021 edition, the `dyn` keyword may be omitted.
+> Before the 2021 edition, the `dyn` keyword may be omitted. In the 2021 edition and beyond, the `dyn` keyword is required semantically.
 
 r[type.trait-object.syntax-edition2018]
 > [!EDITION-2018]
-> In the 2015 edition, if the first bound of the trait object is a path that starts with `::`, then the `dyn` will be treated as a part of the path. The first path can be put in parenthesis to get around this. As such, if you want a trait object with the trait `::your_module::Trait`, you should write it as `dyn (::your_module::Trait)`.
+> In the 2015 edition, `dyn` must be followed by [PathIdentSegment], [LIFETIME_TOKEN], `for`, `(` or `?` to be interpreted as a keyword instead of a regular identifier.
+>
+> Most notably, `dyn`, `dyn::T` and `dyn<T>` will all be treated as type paths. As such, if you want a trait object type with the trait `::module::Trait`, you need to put the path in parentheses and write it as `dyn (::module::Trait)`.
 >
 > Beginning in the 2018 edition, `dyn` is a true keyword and is not allowed in paths, so the parentheses are not necessary.