Skip to content

Fix grammar rules containing or pertaining to bounds #2257

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
fmease wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Fix grammar rules containing or pertaining to bounds #2257

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
bfe0fd9
Fix grammar rules containing bounds
fmease May 5, 2026
9f6b416
Revise section about `dyn` in Rust 2015
fmease May 5, 2026
d43e9b5
Fix grammar rules containing lifetime bounds
fmease May 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/items/generics.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ GenericParams -> `<` ( GenericParam (`,` GenericParam)* `,`? )? `>`

GenericParam -> OuterAttribute* ( LifetimeParam | TypeParam | ConstParam )

LifetimeParam -> Lifetime ( `:` LifetimeBounds )?
LifetimeParam -> Lifetime ( `:` LifetimeBounds? )?

TypeParam -> IDENTIFIER ( `:` Bounds? )? ( `=` Type )?

Expand Down Expand Up @@ -234,7 +234,7 @@ WhereClauseItem ->
LifetimeWhereClauseItem
| TypeBoundWhereClauseItem

LifetimeWhereClauseItem -> Lifetime `:` LifetimeBounds
LifetimeWhereClauseItem -> Lifetime `:` LifetimeBounds?

TypeBoundWhereClauseItem -> ForLifetimes? Type `:` Bounds?
```
Expand Down
2 changes: 1 addition & 1 deletion src/items/type-aliases.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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?)? `;`
```
Expand Down
2 changes: 1 addition & 1 deletion src/paths.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -74,7 +74,7 @@ GenericArgsBinding ->
TypePathSegment `=` Type

GenericArgsBounds ->
TypePathSegment `:` Bounds
TypePathSegment `:` Bounds?
```

r[paths.expr.intro]
Expand Down
4 changes: 2 additions & 2 deletions src/types/impl-trait.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,9 @@ r[type.impl-trait]

r[type.impl-trait.syntax]
```grammar,types
ImplTraitType -> `impl` Bounds
ImplTraitType -> `impl` Bounds?
Copy link
Copy Markdown
Contributor

@ehuss ehuss May 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add a rule somewhere in this chapter that specifies at least one trait must be listed in the bounds? I believe this corresponds to the AtLeastOneTrait error.

ImplTraitTypeOneBound -> `impl` TraitBound
ImplTraitTypeOneBound -> `impl` TraitBound?
```

r[type.impl-trait.intro]
Expand Down
8 changes: 5 additions & 3 deletions src/types/trait-object.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,9 +3,9 @@ r[type.trait-object]

r[type.trait-object.syntax]
```grammar,types
TraitObjectType -> `dyn`? Bounds
TraitObjectType -> Bounds | `dyn` Bounds?
Copy link
Copy Markdown
Contributor

@ehuss ehuss May 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to my other comment, can we have a rule to say at least one trait is required?

I'm not sure if it makes sense to combine that into type.trait-object.constraint or to have a separate rule just below that.


TraitObjectTypeOneBound -> `dyn`? TraitBound
TraitObjectTypeOneBound -> TraitBound | `dyn` TraitBound?
```

r[type.trait-object.intro]
Expand Down Expand Up @@ -37,7 +37,9 @@ r[type.trait-object.syntax-edition2021]

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][grammar-PathIdentSegment], [LIFETIME_OR_LABEL][grammar-LIFETIME_OR_LABEL], `for`, `(` or `?` to be interpreted as the start of a trait object type. Otherwise, it will be interpreted as a regular identifier.
Comment thread
fmease marked this conversation as resolved.
Copy link
Copy Markdown
Contributor

@ehuss ehuss May 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The link destinations aren't required here, since definitions for the rule names are generated automatically.

Suggested change
> In the 2015 edition, `dyn` must be followed by [PathIdentSegment][grammar-PathIdentSegment], [LIFETIME_OR_LABEL][grammar-LIFETIME_OR_LABEL], `for`, `(` or `?` to be interpreted as the start of a trait object type. Otherwise, it will be interpreted as a regular identifier.
> In the 2015 edition, `dyn` must be followed by [PathIdentSegment], [LIFETIME_OR_LABEL], `for`, `(` or `?` to be interpreted as the start of a trait object type. Otherwise, it will be interpreted as a regular identifier.

>
> Most notably, `dyn`, `dyn::T` and `dyn<T>` will all be treated as type paths. The first path can be put in parenthesis to get around this. As such, if you want a trait object with the trait `::module::Trait`, you should 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.

Expand Down
Loading