Fix grammar rules containing or pertaining to bounds by fmease · Pull Request #2257 · rust-lang/reference

fmease · 2026-05-05T08:48:41Z

At least since PR rust-lang/rust#39158 (2017) bounds are intentionally always optional after "bound heralds" (:, impl, dyn). However, the Reference didn't reflect this fact everywhere. This PR rectifies this.

For example reference@master considers the following snippets to be syntactically ill-formed which directly contradicts rustc:

items type T: ;, type T: where;, type T: = U;
type paths T<U: >, T<U<V>: > (as briefly mentioned in PR Fix the grammar of generic arguments #2247)
types impl, fn() -> impl
types dyn, fn() -> dyn
struct T<'a:> where 'a:;

Furthermore, the edition disclaimer for trait object types is incomplete / imprecise / inaccurate:

It states that token sequence dyn:: will be interpreted as the start of a path in Rust 2015 which is correct in isolation but far from complete in context. Per argumentum e contrario, it would wrongly imply that in Rust 2015 the following snippets all contain (bare) trait object types:

type T = dyn;, type T = (dyn);, type T = [dyn];
type T = dyn<>;, type T = dyn<()>;, type T = dyn<<T>::S>;

To address this, I've changed the note to use an exhaustive and positive listing of tokens. The follow set is {PathIdentSegment, LIFETIME_OR_LABEL, for, (, ?} as per rustc's can_begin_dyn_bound_in_edition_2015.

fmease · 2026-05-05T08:49:55Z

 r[type.trait-object.syntax]
 ```grammar,types
-TraitObjectType -> `dyn`? TypeParamBounds
+TraitObjectType -> TypeParamBounds | `dyn` TypeParamBounds?


Due to this grammar rule, TypeParamBounds (now: Bounds) must remain non-empty.

View changes since the review

ehuss

Looks great, thanks!

View changes since this review

fmease · 2026-05-27T12:33:21Z

 fn bar() -> impl Trait {
 }
 ```
+


I'm mirroring the structure of the section about trait object types here with the name vs. constraint split. I'm definitely not married to it. I actually find the rule name name a bit confusing and I feel like the rule sort of mixes syntax and semantics (just like its preexisting sibling for trait object types).

View changes since the review

Looking more closely at this, I agree the ".name" rules don't really make sense.

Generally we don't want to have an English description of the syntax (which is often very imprecise). I'm thinking we can just drop these two .name rules entirely.

fmease · 2026-05-27T12:35:05Z

+`impl Trait` types are written as the keyword `impl` followed by a set of bounds, but with the following restrictions on the bounds:
+
+r[type.impl-trait.constraint]
+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`).


no more than one use<...> bound

This is already mentioned in rule type.impl-trait.generic-capture.precise.constraint-single but it feels logical to mentioned it here to be exhaustive.

View changes since the review

Yea, normally I don't like duplicating things since it makes it more difficult to maintain. But in this case it seems reasonable.

fmease · 2026-05-27T13:14:12Z

+`impl Trait` types are written as the keyword `impl` followed by a set of bounds, but with the following restrictions on the bounds:
+
+r[type.impl-trait.constraint]
+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`).


no more than one opt-out bound (e.g. ?Sized)

Copying the terminology from the trait object section. Personally speaking I call them relaxed bounds and that's what the compiler calls them now everywhere, too (it used to call them relaxed bounds, maybe bounds and unbounds).

Strictly speaking, duplicate relaxed bounds are forbidden but on stable that doesn't make a difference since there's only one trait that can be relaxed (Sized).

It felt natural to mention this here but of course, relaxed bounds (and use<..> bounds) come with a lot more semantic restrictions (specifically when it comes to legal locations) but the Reference doesn't have a central place to talk about them¹.

View changes since the review

Footnotes

E.g., for the longest time ?Trait was allowed even for Trait != Sized but two years ago or so that was finally made an error but the Reference was never updated. ↩

fmease · 2026-05-27T13:23:09Z


-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]


Changed it to bounds from constraint since the corresponding rule for impl-Trait had to be renamed to bounds not to conflict with the preexisting types.impl-trait.constraint.

View changes since the review

fmease · 2026-06-07T13:41:36Z

 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_OR_LABEL], `for`, `(` or `?` to be interpreted as the start of a trait object type. Otherwise, it will be interpreted as a regular identifier.


FIXME: Imprecise language: In Rust 2015 dyn+ is a legal trait object type where dyn indeed isn't a keyword but the name of the trait, so strictly speaking dyn is actually "interpreted as the start of a trait object type". This sentence needs to be reworded to say something about dyn being an "active keyword" if followed by XY // something of that nature.

View changes since the review

ehuss · 2026-06-11T01:26:35Z

+TraitObjectType -> Bounds | `dyn` Bounds?

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


Just wanted to double-check. The reason for adding the variants without dyn is because the requirement for dyn is done during validation and not during parsing, correct?

If so, I'm thinking of adding a footnote on these to point to type.trait-object.syntax-edition2021 like we do in other places like ExternBlock where old edition syntax could be potentially confusing to readers.

View changes since the review

rustbot · 2026-06-16T21:47:40Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

fmease · 2026-06-16T21:53:18Z

What changed since the your review:

Removed rule type.trait-object.name as per your review comment & parts of type.trait-object.bounds as per my own review comment.
Clarified the section about dyn in Rust 2015 to address my own concern
Added footnotes to the grammar of trait object types to highlight edition-sensitive parts to address this review comment
Replaced LIFETIME_OR_LABEL with LIFETIME_TOKEN in the Rust 2015 dyn paragraph. I accidentally mixed them up and wrongly thought the "or label" one was the more general of the two. Obviously, dyn 'static (where we have a ticked keyword) is a syntactically valid trait object type in Rust 2015.

Ready for re-review.

`struct T<'a:> where 'a:;` is syntactically valid.

Furthermore, drop rule `type.trait-object.name` entirely and parts of `type.trait-object.bounds` since they mixed syntax & semantics and tried to redescribe the grammar in prose which didn't add value, were too ambiguous & incomplete.

rustbot added the S-waiting-on-review Status: The marked PR is awaiting review from a maintainer label May 5, 2026

fmease commented May 5, 2026

View reviewed changes

fmease force-pushed the fix-bounds-grammars branch from 4200b2e to 7b807ac Compare May 5, 2026 10:25

fmease commented May 5, 2026

View reviewed changes

Comment thread src/types/trait-object.md Outdated

This comment has been minimized.

Sign in to view

fmease force-pushed the fix-bounds-grammars branch from 7b807ac to e8c2309 Compare May 6, 2026 13:38

This comment has been minimized.

Sign in to view

fmease force-pushed the fix-bounds-grammars branch from e8c2309 to 9f6b416 Compare May 11, 2026 21:21

This comment has been minimized.

Sign in to view

ehuss reviewed May 24, 2026

View reviewed changes

Comment thread src/types/impl-trait.md

Comment thread src/types/trait-object.md Outdated

Comment thread src/types/trait-object.md Outdated

fmease force-pushed the fix-bounds-grammars branch from d43e9b5 to 5fd453f Compare May 27, 2026 12:22

fmease commented May 27, 2026

View reviewed changes

Comment thread src/types/trait-object.md Outdated

fmease commented May 27, 2026

View reviewed changes

fmease force-pushed the fix-bounds-grammars branch from 5fd453f to 1a54708 Compare May 27, 2026 13:17

fmease commented May 27, 2026

View reviewed changes

fmease mentioned this pull request Jun 7, 2026

Rust 2015 type dyn + dyn wrongly rejected by the parser due to "helpful" diagnostic rust-lang/rust#157565

Closed

fmease commented Jun 7, 2026

View reviewed changes

ehuss reviewed Jun 11, 2026

View reviewed changes

fmease force-pushed the fix-bounds-grammars branch from 1a54708 to a88a302 Compare June 16, 2026 21:47

Fix grammar rules containing bounds

2d391df

fmease force-pushed the fix-bounds-grammars branch from a88a302 to eb08631 Compare June 16, 2026 22:04

fmease added 2 commits June 17, 2026 00:05

Revise section about dyn in Rust 2015

f68a527

Fix grammar rules containing lifetime bounds

def41e9

`struct T<'a:> where 'a:;` is syntactically valid.

fmease commented Jun 16, 2026

View reviewed changes

Comment thread src/types/trait-object.md Outdated

fmease force-pushed the fix-bounds-grammars branch from eb08631 to 362c0ee Compare June 16, 2026 22:20

Add some footnotes to the grammar of trait object types

362c0ee

Conversation

fmease commented May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fmease May 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

ehuss left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

fmease May 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ehuss Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

fmease May 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ehuss Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

fmease May 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Footnotes

Uh oh!

fmease May 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fmease Jun 7, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ehuss Jun 11, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Jun 16, 2026

Uh oh!

fmease commented Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

fmease commented May 5, 2026 •

edited

Loading

fmease May 5, 2026 •

edited

Loading

ehuss left a comment •

edited by rustbot

Loading

fmease May 27, 2026 •

edited by rustbot

Loading

fmease May 27, 2026 •

edited by rustbot

Loading

fmease May 27, 2026 •

edited by rustbot

Loading

fmease May 27, 2026 •

edited by rustbot

Loading

fmease Jun 7, 2026 •

edited by rustbot

Loading

ehuss Jun 11, 2026 •

edited by rustbot

Loading

fmease commented Jun 16, 2026 •

edited

Loading