From 95081a7162313a3199b5ede7bfdc7799b0f5c52c Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 10:28:40 +0000 Subject: [PATCH 01/10] Add `.intro` rules where missing We want all body text to fall under a leaf rule. We put intro text under `.intro` rules, but we were missing some. Let's add `.intro` rule identifiers where these were missing. --- src/attributes/codegen.md | 1 + src/attributes/debugger.md | 1 + src/attributes/diagnostics.md | 2 ++ src/attributes/limits.md | 1 + src/attributes/testing.md | 1 + src/attributes/type_system.md | 1 + src/comments.md | 1 + src/destructors.md | 1 + src/items/use-declarations.md | 1 + src/keywords.md | 1 + src/lifetime-elision.md | 1 + src/macro-ambiguity.md | 1 + src/memory-model.md | 1 + src/names/namespaces.md | 1 + src/names/scopes.md | 2 ++ src/paths.md | 1 + src/runtime.md | 1 + src/special-types-and-traits.md | 1 + src/tokens.md | 1 + src/type-layout.md | 1 + src/types/boolean.md | 1 + src/unsafe-keyword.md | 1 + 22 files changed, 24 insertions(+) diff --git a/src/attributes/codegen.md b/src/attributes/codegen.md index 4e88f6af79..b1a79f3edc 100644 --- a/src/attributes/codegen.md +++ b/src/attributes/codegen.md @@ -1,6 +1,7 @@ r[attributes.codegen] # Code generation attributes +r[attributes.codegen.intro] The following [attributes] are used for controlling code generation. diff --git a/src/attributes/debugger.md b/src/attributes/debugger.md index a7146a52bb..7f9372fc4f 100644 --- a/src/attributes/debugger.md +++ b/src/attributes/debugger.md @@ -1,6 +1,7 @@ r[attributes.debugger] # Debugger attributes +r[attributes.debugger.intro] The following [attributes] are used for enhancing the debugging experience when using third-party debuggers like GDB or WinDbg. diff --git a/src/attributes/diagnostics.md b/src/attributes/diagnostics.md index a42223630d..822fde24b5 100644 --- a/src/attributes/diagnostics.md +++ b/src/attributes/diagnostics.md @@ -1,12 +1,14 @@ r[attributes.diagnostics] # Diagnostic attributes +r[attributes.diagnostics.intro] The following [attributes] are used for controlling or generating diagnostic messages during compilation. r[attributes.diagnostics.lint] ## Lint check attributes +r[attributes.diagnostics.lint.intro] A lint check names a potentially undesirable coding pattern, such as unreachable code or omitted documentation. diff --git a/src/attributes/limits.md b/src/attributes/limits.md index bb88b872dc..c07020c761 100644 --- a/src/attributes/limits.md +++ b/src/attributes/limits.md @@ -1,6 +1,7 @@ r[attributes.limits] # Limits +r[attributes.limits.intro] The following [attributes] affect compile-time limits. r[attributes.limits.recursion_limit] diff --git a/src/attributes/testing.md b/src/attributes/testing.md index 87d43453d2..28c57ba514 100644 --- a/src/attributes/testing.md +++ b/src/attributes/testing.md @@ -1,6 +1,7 @@ r[attributes.testing] # Testing attributes +r[attributes.testing.intro] The following [attributes] are used for specifying functions for performing tests. Compiling a crate in "test" mode enables building the test functions along with a test harness for executing the tests. Enabling the test mode also diff --git a/src/attributes/type_system.md b/src/attributes/type_system.md index 032d8ba9d1..cecf911e40 100644 --- a/src/attributes/type_system.md +++ b/src/attributes/type_system.md @@ -1,6 +1,7 @@ r[attributes.type-system] # Type system attributes +r[attributes.type-system.intro] The following [attributes] are used for changing how a type can be used. r[attributes.type-system.non_exhaustive] diff --git a/src/comments.md b/src/comments.md index 64b90d8e36..7102bf5825 100644 --- a/src/comments.md +++ b/src/comments.md @@ -50,6 +50,7 @@ BLOCK_COMMENT_OR_DOC -> r[comments.normal] ## Non-doc comments +r[comments.normal.intro] Comments follow the general C++ style of line (`//`) and block (`/* ... */`) comment forms. Nested block comments are supported. r[comments.normal.tokenization] diff --git a/src/destructors.md b/src/destructors.md index 6dd5554db7..d8767c2cf5 100644 --- a/src/destructors.md +++ b/src/destructors.md @@ -381,6 +381,7 @@ Promotion of a value expression to a `'static` slot occurs when the expression c r[destructors.scope.lifetime-extension] ### Temporary lifetime extension +r[destructors.scope.lifetime-extension.intro] > [!NOTE] > The exact rules for temporary lifetime extension are subject to change. This is describing the current behavior only. diff --git a/src/items/use-declarations.md b/src/items/use-declarations.md index 20cad43b3d..24fa703f93 100644 --- a/src/items/use-declarations.md +++ b/src/items/use-declarations.md @@ -368,6 +368,7 @@ m!(use std as _;); r[items.use.restrictions] ## Restrictions +r[items.use.restrictions.intro] The following rules are restrictions for valid `use` declarations. r[items.use.restrictions.crate-alias] diff --git a/src/keywords.md b/src/keywords.md index 39cc04c1c1..33aee602e5 100644 --- a/src/keywords.md +++ b/src/keywords.md @@ -1,6 +1,7 @@ r[lex.keywords] # Keywords +r[lex.keywords.intro] Rust divides keywords into three categories: * [strict](#strict-keywords) diff --git a/src/lifetime-elision.md b/src/lifetime-elision.md index 9cc1ff86ab..a4a372eae7 100644 --- a/src/lifetime-elision.md +++ b/src/lifetime-elision.md @@ -1,6 +1,7 @@ r[lifetime-elision] # Lifetime elision +r[lifetime-elision.intro] Rust has rules that allow lifetimes to be elided in various places where the compiler can infer a sensible default choice. r[lifetime-elision.function] diff --git a/src/macro-ambiguity.md b/src/macro-ambiguity.md index 231fd2c8cf..959b60e104 100644 --- a/src/macro-ambiguity.md +++ b/src/macro-ambiguity.md @@ -1,6 +1,7 @@ r[macro.ambiguity] # Appendix: Macro follow-set ambiguity formal specification +r[macro.ambiguity.intro] This page documents the formal specification of the follow rules for [Macros By Example]. They were originally specified in [RFC 550], from which the bulk of this text is copied, and expanded upon in subsequent RFCs. r[macro.ambiguity.convention] diff --git a/src/memory-model.md b/src/memory-model.md index cc3cf02ec0..b4efe0f822 100644 --- a/src/memory-model.md +++ b/src/memory-model.md @@ -1,6 +1,7 @@ r[memory] # Memory model +r[memory.intro] > [!WARNING] > The memory model of Rust is incomplete and not fully decided. diff --git a/src/names/namespaces.md b/src/names/namespaces.md index 58a96c7faf..77509126e9 100644 --- a/src/names/namespaces.md +++ b/src/names/namespaces.md @@ -80,6 +80,7 @@ fn example<'Foo>(f: Foo) { r[names.namespaces.without] ## Named entities without a namespace +r[names.namespaces.without.intro] The following entities have explicit names, but the names are not a part of any specific namespace. ### Fields diff --git a/src/names/scopes.md b/src/names/scopes.md index 44c3dbf788..3f65f9c18d 100644 --- a/src/names/scopes.md +++ b/src/names/scopes.md @@ -34,6 +34,7 @@ Similar to items within a module or block, it is an error to introduce an item r[names.scopes.pattern-bindings] ## Pattern binding scopes +r[names.scopes.pattern-bindings.intro] The scope of a local variable [pattern] binding depends on where it is used: r[names.scopes.pattern-bindings.let] @@ -144,6 +145,7 @@ trait SomeTrait<'a, T, const N: usize> { r[names.scopes.lifetimes] ### Lifetime scopes +r[names.scopes.lifetimes.intro] Lifetime parameters are declared in a [GenericParams] list and [higher-ranked trait bounds][hrtb]. r[names.scopes.lifetimes.special] diff --git a/src/paths.md b/src/paths.md index 933409f7e9..81484efde4 100644 --- a/src/paths.md +++ b/src/paths.md @@ -188,6 +188,7 @@ type G = std::boxed::Box isize>; r[paths.qualifiers] ## Path qualifiers +r[paths.qualifiers.intro] Paths can be denoted with various leading qualifiers to change the meaning of how it is resolved. > [!NOTE] diff --git a/src/runtime.md b/src/runtime.md index 3b72b0f9ee..651d7c9c7a 100644 --- a/src/runtime.md +++ b/src/runtime.md @@ -1,6 +1,7 @@ r[runtime] # The Rust runtime +r[runtime.intro] This section documents features that define some aspects of the Rust runtime. diff --git a/src/special-types-and-traits.md b/src/special-types-and-traits.md index 3f7589113e..e508bf155e 100644 --- a/src/special-types-and-traits.md +++ b/src/special-types-and-traits.md @@ -143,6 +143,7 @@ The [`Termination`] trait indicates the acceptable return types for the [main fu r[lang-types.auto-traits] ## Auto traits +r[lang-types.auto-traits.intro] The [`Send`], [`Sync`], [`Unpin`], [`UnwindSafe`], and [`RefUnwindSafe`] traits are _auto traits_. Auto traits have special properties. r[lang-types.auto-traits.auto-impl] diff --git a/src/tokens.md b/src/tokens.md index 0d310ad76b..bcd91103eb 100644 --- a/src/tokens.md +++ b/src/tokens.md @@ -38,6 +38,7 @@ Within this documentation's grammar, "simple" tokens are given in [string table r[lex.token.literal] ## Literals +r[lex.token.literal.intro] Literals are tokens used in [literal expressions]. ### Examples diff --git a/src/type-layout.md b/src/type-layout.md index 70b26aac32..369547e0d1 100644 --- a/src/type-layout.md +++ b/src/type-layout.md @@ -12,6 +12,7 @@ Note that even types with the same layout can still differ in how they are passe r[layout.properties] ## Size and alignment +r[layout.properties.intro] All values have an alignment and size. r[layout.properties.align] diff --git a/src/types/boolean.md b/src/types/boolean.md index b02abfa052..4f07b6eb04 100644 --- a/src/types/boolean.md +++ b/src/types/boolean.md @@ -41,6 +41,7 @@ Like all primitives, the boolean type [implements][p-impl] the [traits][p-traits r[type.bool.expr] ## Operations on boolean values +r[type.bool.expr.intro] When using certain operator expressions with a boolean type for its operands, they evaluate using the rules of [boolean logic]. r[type.bool.expr.not] diff --git a/src/unsafe-keyword.md b/src/unsafe-keyword.md index 9153078fc0..8c72539086 100644 --- a/src/unsafe-keyword.md +++ b/src/unsafe-keyword.md @@ -73,6 +73,7 @@ Unsafe trait implementations are the logical dual to unsafe traits: where unsafe r[unsafe.extern] ## Unsafe external blocks (`unsafe extern`) +r[unsafe.extern.intro] The programmer who declares an [external block] must assure that the signatures of the items contained within are correct. Failing to do so may lead to undefined behavior. That this obligation has been met is indicated by writing `unsafe extern`. r[unsafe.extern.edition2024] From 29418627f6a537c7b206a07f72f7d060c2d186b4 Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 10:29:26 +0000 Subject: [PATCH 02/10] Move `.intro` rules to cover leading notes and examples In some cases, the `.intro` rule fell below a leading admonition or example. This left text under a non-leaf rule, which we want to avoid. This leading text is logically part of the introduction, so let's move the rule identifiers where needed to cover this text. --- src/linkage.md | 2 +- src/types/boolean.md | 2 +- src/types/impl-trait.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/linkage.md b/src/linkage.md index 4b4e6edc35..5f5dd9b858 100644 --- a/src/linkage.md +++ b/src/linkage.md @@ -1,10 +1,10 @@ r[link] # Linkage +r[link.intro] > [!NOTE] > This section is described more in terms of the compiler than of the language. -r[link.intro] The compiler supports various methods to link crates together both statically and dynamically. This section will explore the various methods to link crates together, and more information about native libraries can be found in the [FFI section of the book][ffi]. [ffi]: ../book/ch20-01-unsafe-rust.html#using-extern-functions-to-call-external-code diff --git a/src/types/boolean.md b/src/types/boolean.md index 4f07b6eb04..7da7f30ec7 100644 --- a/src/types/boolean.md +++ b/src/types/boolean.md @@ -1,11 +1,11 @@ r[type.bool] # Boolean type +r[type.bool.intro] ```rust let b: bool = true; ``` -r[type.bool.intro] The *boolean type* or *bool* is a primitive data type that can take on one of two values, called *true* and *false*. r[type.bool.literal] diff --git a/src/types/impl-trait.md b/src/types/impl-trait.md index 098547c0b6..e5f05a4d40 100644 --- a/src/types/impl-trait.md +++ b/src/types/impl-trait.md @@ -30,10 +30,10 @@ There must be at least one trait bound, no more than one `use<..>` bound, and no r[type.impl-trait.param] ## Anonymous type parameters +r[type.impl-trait.param.intro] > [!NOTE] > This is often called "impl Trait in argument position". (The term "parameter" is more correct here, but "impl Trait in argument position" is the phrasing used during the development of this feature, and it remains in parts of the implementation.) -r[type.impl-trait.param.intro] Functions can use `impl` followed by a set of trait bounds to declare a parameter as having an anonymous type. The caller must provide a type that satisfies the bounds declared by the anonymous type parameter, and the function can only use the methods available through the trait bounds of the anonymous type parameter. For example, these two forms are almost equivalent: @@ -59,10 +59,10 @@ That is, `impl Trait` in argument position is syntactic sugar for a generic type r[type.impl-trait.return] ## Abstract return types +r[type.impl-trait.return.intro] > [!NOTE] > This is often called "impl Trait in return position". -r[type.impl-trait.return.intro] Functions can use `impl Trait` to return an abstract return type. These types stand in for another concrete type where the caller may only use the methods declared by the specified `Trait`. r[type.impl-trait.return.constraint-body] From 8bb6d4e0f26c47612d35ea439cec3cfe1e099704 Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 10:31:15 +0000 Subject: [PATCH 03/10] Fix too-nested `items.generics.syntax` rules We had rules under `items.generics.syntax` that should instead be its siblings. Let's promote these. --- src/items/generics.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/items/generics.md b/src/items/generics.md index 75f16d43c4..1f9cab7b1b 100644 --- a/src/items/generics.md +++ b/src/items/generics.md @@ -16,13 +16,13 @@ ConstParam -> ( `=` ( BlockExpression | IDENTIFIER | `-`?LiteralExpression ) )? ``` -r[items.generics.syntax.intro] +r[items.generics.intro] [Functions], [type aliases], [structs], [enumerations], [unions], [traits], and [implementations] may be *parameterized* by types, constants, and lifetimes. These parameters are listed in angle brackets (`<...>`), usually immediately after the name of the item and before its definition. For implementations, which don't have a name, they come directly after `impl`. -r[items.generics.syntax.decl-order] +r[items.generics.decl-order] The order of generic parameters is restricted to lifetime parameters and then type and const parameters intermixed. -r[items.generics.syntax.duplicate-params] +r[items.generics.duplicate-params] The same parameter name may not be declared more than once in a [GenericParams] list. Some examples of items with type, const, and lifetime parameters: @@ -35,7 +35,7 @@ struct InnerArray([T; N]); struct EitherOrderWorks(U); ``` -r[items.generics.syntax.scope] +r[items.generics.scope] Generic parameters are in scope within the item definition where they are declared. They are not in scope for items declared within the body of a function as described in [item declarations]. See [generic parameter scopes] for more details. r[items.generics.builtin-generic-types] From fad35e1a40c2bad9c20f54de5995c2867131ce2b Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 22:40:18 +0000 Subject: [PATCH 04/10] Add rule ID for function-local macro declarations We say that macros can be declared and used locally, but we were missing a rule identifier for this. Let's add one. --- src/macros-by-example.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/macros-by-example.md b/src/macros-by-example.md index a91b6a2be4..267304c7cb 100644 --- a/src/macros-by-example.md +++ b/src/macros-by-example.md @@ -245,6 +245,7 @@ mod inner { m!(1); ``` +r[macro.decl.scope.textual.function-local] Macros can be declared and used locally inside functions as well, and work similarly: ```rust From d335131ed0cfe76f8a94d24445f7582cfa0c772d Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 22:40:37 +0000 Subject: [PATCH 05/10] Fix macro textual scope shadowing link target In name resolution, we say that one way in which names introduced by `use` declarations can be shadowed within a single scope is by macro textual scope shadowing. We then linked to a rule that says it's not an error to define a macro multiple times, but that's discussing only textual-scope matters. A `use` declaration creates a path-based scope binding, so let's point instead to the rule that says that textual scope name bindings shadow path-based scope bindings. --- src/names/name-resolution.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/names/name-resolution.md b/src/names/name-resolution.md index e58a956cc2..cd27be47b5 100644 --- a/src/names/name-resolution.md +++ b/src/names/name-resolution.md @@ -576,7 +576,7 @@ r[names.resolution.type-relative] [glob import]: items.use.glob [item definitions]: ../items.md [macro invocations]: ../macros.md#macro-invocation -[macro textual scope shadowing]: ../macros-by-example.md#r-macro.decl.scope.textual.shadow +[macro textual scope shadowing]: macro.decl.scope.textual.shadow-path-based [name resolution ambiguities]: #r-names.resolution.expansion.imports.ambiguity [namespaces]: ../names/namespaces.md [outer scope]: #r-names.resolution.general.scopes From 9150fd2c29abe3e10f67e09d643afcd8cc0321ae Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 22:41:10 +0000 Subject: [PATCH 06/10] Split drop-order sentence out from nesting rule We have a set of rules that describe how drop scopes are nested. There's a rule that provides a lead-in for this. That rule also contained a claim about the drop order when multiple scopes are left at once. Let's break that claim out into its own rule so that we can cite it separately. --- src/destructors.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/destructors.md b/src/destructors.md index d8767c2cf5..0103093cf9 100644 --- a/src/destructors.md +++ b/src/destructors.md @@ -84,7 +84,7 @@ r[destructors.scope.match-arm] * Each arm of a `match` expression r[destructors.scope.nesting] -Drop scopes are nested within one another as follows. When multiple scopes are left at once, such as when returning from a function, variables are dropped from the inside outwards. +Drop scopes are nested within one another as follows: r[destructors.scope.nesting-function] * The entire function scope is the outer most scope. @@ -113,6 +113,9 @@ r[destructors.scope.nesting-match] r[destructors.scope.nesting-other] * The parent of all other scopes is the scope of the immediately enclosing expression. +r[destructors.scope.nesting-drop-order] +When multiple scopes are left at once, such as when returning from a function, variables are dropped from the inside outwards. + r[destructors.scope.params] ### Scopes of function parameters From a772111e53420ff82024c1dcdcdfc5d9938905c5 Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 10:34:02 +0000 Subject: [PATCH 07/10] Split lint group rules We had combined the introduction for lint groups with a specific claim that using a named lint group is equivalent to listing out the lints within that group. Let's separate out that claim into its own rule, and let's add a `.intro` rule for the introduction. --- src/attributes/diagnostics.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/src/attributes/diagnostics.md b/src/attributes/diagnostics.md index 822fde24b5..fd620d9374 100644 --- a/src/attributes/diagnostics.md +++ b/src/attributes/diagnostics.md @@ -229,9 +229,11 @@ pub fn another_example() { r[attributes.diagnostics.lint.group] ### Lint groups -Lints may be organized into named groups so that the level of related lints -can be adjusted together. Using a named group is equivalent to listing out the -lints within that group. +r[attributes.diagnostics.lint.group.intro] +Lints may be organized into named groups so that the level of related lints can be adjusted together. + +r[attributes.diagnostics.lint.group.equivalence] +Using a named group is equivalent to listing out the lints within that group. ```rust,compile_fail // This allows all lints in the "unused" group. From 2a73462dc228b4a36c5bf8ec9a35e55ebd2447d7 Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 10:34:28 +0000 Subject: [PATCH 08/10] Add rule ID for variadic function syntax We're missing a rule identifier above the description of the syntax for variadic functions. Let's add that. --- src/items/external-blocks.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/items/external-blocks.md b/src/items/external-blocks.md index ccb8dd52f4..662fb235ce 100644 --- a/src/items/external-blocks.md +++ b/src/items/external-blocks.md @@ -215,6 +215,7 @@ Like `"C"` and `"system"`, most platform-specific ABI strings also have a [corre r[items.extern.variadic] ## Variadic functions +r[items.extern.variadic.syntax] Functions within external blocks may be made variadic by specifying `...` as the last parameter. The variadic parameter may be specified with a pattern. ```rust From 19330a51e1437f23a9379339902c735093c5b296 Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 10:35:05 +0000 Subject: [PATCH 09/10] Make stray subrules into siblings Some rules that qualify other rules are identified as subrules rather than as siblings (as they should be). Let's fix that. --- src/attributes/diagnostics.md | 2 +- src/items/implementations.md | 2 +- src/items/static-items.md | 2 +- src/type-layout.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/attributes/diagnostics.md b/src/attributes/diagnostics.md index fd620d9374..f2f6b62bae 100644 --- a/src/attributes/diagnostics.md +++ b/src/attributes/diagnostics.md @@ -399,7 +399,7 @@ struct MustUse(); MustUse(); // ERROR: Unused value that must be used. ``` -r[attributes.diagnostics.must_use.type.uninhabited] +r[attributes.diagnostics.must_use.type-uninhabited] As an exception to [attributes.diagnostics.must_use.type], the lint does not fire for `Result<(), E>` when `E` is [uninhabited] or for `ControlFlow` when `B` is [uninhabited]. A `#[non_exhaustive]` type from an external crate is not considered uninhabited for this purpose, because it may gain constructors in the future. ```rust diff --git a/src/items/implementations.md b/src/items/implementations.md index 12764a433a..967d87bc5b 100644 --- a/src/items/implementations.md +++ b/src/items/implementations.md @@ -41,7 +41,7 @@ The nominal type is called the _implementing type_ and the associable items are r[items.impl.inherent.associated-items] Inherent implementations associate the contained items to the implementing type. -r[items.impl.inherent.associated-items.allowed-items] +r[items.impl.inherent.allowed-items] Inherent implementations can contain [associated functions] (including [methods]) and [associated constants]. r[items.impl.inherent.type-alias] diff --git a/src/items/static-items.md b/src/items/static-items.md index 395d69c3ce..d3fc458e87 100644 --- a/src/items/static-items.md +++ b/src/items/static-items.md @@ -33,7 +33,7 @@ All access to a static is safe, but there are a number of restrictions on static r[items.static.sync] * The type must have the [`Sync`](std::marker::Sync) trait bound to allow thread-safe access. -r[items.static.init.omission] +r[items.static.init-omission] The initializer expression must be omitted in an [external block], and must be provided for free static items. r[items.static.safety-qualifiers] diff --git a/src/type-layout.md b/src/type-layout.md index 369547e0d1..daec57f9ea 100644 --- a/src/type-layout.md +++ b/src/type-layout.md @@ -176,7 +176,7 @@ The only data layout guarantees made by this representation are those required f 1. The offset of a field is divisible by that field's alignment. 2. The alignment of the type is at least the maximum alignment of its fields. -r[layout.repr.rust.layout.struct] +r[layout.repr.rust.struct] For [structs], it is further guaranteed that the fields do not overlap. That is, the fields can be ordered such that the offset plus the size of any field is less than or equal to the offset of the next field in the ordering. The ordering does not have to be the same as the order in which the fields are specified in the declaration of the type. Be aware that this guarantee does not imply that the fields have distinct addresses: [zero-sized types] may have the same address as other fields in the same struct. From 2f428f7cd3bb879f056611dca6c06b9e53d60aed Mon Sep 17 00:00:00 2001 From: Travis Cross Date: Sat, 29 Aug 2026 11:17:01 +0000 Subject: [PATCH 10/10] Fix `edition2024` rule IDs in patterns chapter Some of the edition admonitions in the patterns chapter have rule identifiers that mark them as subrules when they should be siblings. Let's fix that. --- src/patterns.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/patterns.md b/src/patterns.md index 05ad64c97f..cff9c0fe91 100644 --- a/src/patterns.md +++ b/src/patterns.md @@ -324,7 +324,7 @@ let [ref x] = &[()]; //~ ERROR let [ref mut x] = &mut [()]; //~ ERROR ``` -r[patterns.ident.binding.mode-limitations.edition2024] +r[patterns.ident.binding.mode-limitations-binding-edition2024] > [!EDITION-2024] > Before the 2024 edition, bindings could explicitly specify a `ref` or `ref mut` binding mode even when the default binding mode was not "move", and they could specify mutability on such bindings with `mut`. In these editions, specifying `mut` on a binding set the binding mode to "move" regardless of the current default binding mode. @@ -335,7 +335,7 @@ Similarly, a reference pattern may only appear when the default binding mode is let [&x] = &[&()]; //~ ERROR ``` -r[patterns.ident.binding.mode-limitations-reference.edition2024] +r[patterns.ident.binding.mode-limitations-reference-edition2024] > [!EDITION-2024] > Before the 2024 edition, reference patterns could appear even when the default binding mode was not "move", and had both the effect of matching against the scrutinee and of causing the default binding mode to be reset to "move".