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

rustbot · 2026-05-11T21:21:26Z

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.

ehuss

Looks great, thanks!

View changes since this review

ehuss · 2026-05-24T00:52:42Z

 r[type.impl-trait.syntax]
 ```grammar,types
-ImplTraitType -> `impl` Bounds
+ImplTraitType -> `impl` Bounds?


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.

ehuss · 2026-05-24T01:02:51Z

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


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.

ehuss · 2026-05-24T01:03:57Z

 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.


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.

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

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


 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.
+Trait object types are written as the keyword `dyn` followed by a set of bounds, but with the following restrictions on the bounds:


followed by a set of […] bounds

(preexisting) Is set generally to be understood as a mathematical set in the Reference? Is it defined anywhere? Right now, it's unclear to me if this sentence makes any statements about duplicate bounds. As you know, dyn Trait + 'a + 'a and dyn NonAutoTrait + NonAutoTrait are illegal and dyn Sync + Sync is legal...

View changes since the 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

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

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

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

Fix grammar rules containing bounds

bfe0fd9

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

ehuss reviewed May 24, 2026

View reviewed changes

fmease added 2 commits May 27, 2026 12:47

Revise section about dyn in Rust 2015

ec3a9e7

Fix grammar rules containing lifetime bounds

c481337

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

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

Note down some semantic restrictions on dyn-Trait and impl-Trait

1a54708

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

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

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.

rustbot commented May 11, 2026

Uh oh!

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!

ehuss May 24, 2026

Choose a reason for hiding this comment

Uh oh!

ehuss May 24, 2026

Choose a reason for hiding this comment

Uh oh!

ehuss May 24, 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!

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

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 May 27, 2026 •

edited by rustbot

Loading