-
Notifications
You must be signed in to change notification settings - Fork 487
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.
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
Document inline const/const block expression #1295
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You also need to update the chapter on constant evaluation to include these as a const context.
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in rust-lang#76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in rust-lang#77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. rust-lang#89964). The inference is implemented in rust-lang#89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in rust-lang#96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: rust-lang#86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
Stabilise inline_const # Stabilisation Report ## Summary This PR will stabilise `inline_const` feature in expression position. `inline_const_pat` is still unstable and will *not* be stabilised. The feature will allow code like this: ```rust foo(const { 1 + 1 }) ``` which is roughly desugared into ```rust struct Foo; impl Foo { const FOO: i32 = 1 + 1; } foo(Foo::FOO) ``` This feature is from rust-lang/rfcs#2920 and is tracked in #76001 (the tracking issue should *not* be closed as it needs to track inline const in pattern position). The initial implementation is done in #77124. ## Difference from RFC There are two major differences (enhancements) as implemented from the RFC. First thing is that the RFC says that the type of an inline const block inferred from the content *within* it, but we currently can infer the type using the information from outside the const block as well. This is a frequently requested feature to the initial implementation (e.g. #89964). The inference is implemented in #89561 and is done by treating inline const similar to a closure and therefore share inference context with its parent body. This allows code like: ```rust let v: Vec<i32> = const { Vec::new() }; ``` Another enhancement that differs from the RFC is that we currently allow inline consts to reference generic parameters. This is implemented in #96557. This allows code like: ```rust fn create_none_array<T, const N: usize>() -> [Option<T>; N] { [const { None::<T> }; N] } ``` This enhancement also makes inline const usable as static asserts: ```rust fn require_zst<T>() { const { assert!(std::mem::size_of::<T>() == 0) } } ``` ## Documentation Reference: rust-lang/reference#1295 ## Unresolved issues We still have a few issues that are not resolved, but I don't think it necessarily has to block stabilisation: * expr fragment specifier issue: #86730 * ~~`const {}` behaves similar to `async {}` but not to `{}` and `unsafe {}` (they are treated as `ExpressionWithoutBlock` rather than `ExpressionWithBlock`): https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/const.20blocks.20differ.20from.20normal.20and.20from.20unsafe.20blocks/near/290229453~~ ## Tests There are a few tests in https://github.com/rust-lang/rust/tree/master/src/test/ui/inline-const
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbdd0121 Sorry I dropped the ball of the review here.
Can you update or answer these questions?
- Can you respond to the review comments above?
- It looks like this changed during the stabilization effort, such as changing to ExpressionWithBlock. Can you update the text for any changes that happened?
- Do all the rules and restrictions of a constant item hold for a const block? If so, can it say that? If not, can it explain the differences and similarities. For example, are they always evalutated?
- Should const blocks be added to the list of constant expressions?
- Is it also a const context? If so, can it be added there.
- My understanding is that this does not match
expr
in a macro. If that is correct, can you update theexpr
docs to mention that limitation? I understand this might change for the edition, but it doesn't look like that work has finished.
src/expressions/block-expr.md
Outdated
fn main() { | ||
const FOO: i32 = 1 + 1; | ||
let x = foo(FOO); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The stabilization report said that it is more equivalent to an associated const. Why the difference?
Also, this doesn't seem quite equivalent, since it seems like const blocks can refer to surrounding generics. Can this be more explicit about the ability to refer to generics?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Auto-merge is enabled but nothing is happening...? |
Thanks, I didn't see that it was blocked. |
Update books ## rust-lang/book 8 commits in bebcf527e67755a989a1739b7cfaa8f0e6b30040..5e9051f71638aa941cd5dda465e25c61cde9594f 2024-05-16 14:58:56 UTC to 2024-05-07 23:58:22 UTC - Convert ch01-03-hello-cargo.md Listing 1-2 using `<Listing>` (rust-lang/book#3924) - infra: fix rendering bug in mdbook-trpl-note (rust-lang/book#3925) - infra: support `Listing`s without `file-name` (rust-lang/book#3920) - Add a `<Listing>` preprocessor (rust-lang/book#3918) - Update explanation according to code listing (rust-lang/book#3916) - infra: run package tests (rust-lang/book#3915) - Fix workspace behavior by excluding `listings` (rust-lang/book#3914) - Backport changes to chapter 8 (rust-lang/book#3913) ## rust-embedded/book 1 commits in 17842ebb050f62e40a4618edeb8e8ee86e758707..dd962bb82865a5284f2404e5234f1e3222b9c022 2024-05-17 23:43:59 UTC to 2024-05-17 23:43:59 UTC - 'llvm-tools-preview' component is now named 'llvm-tools' (rust-embedded/book#372) ## rust-lang/reference 2 commits in 51817951d0d213a0011f82b62aae02c3b3f2472e..e356977fceaa8591c762312d8d446769166d4b3e 2024-05-10 12:49:15 UTC to 2024-05-07 13:32:57 UTC - Document inline const/const block expression (rust-lang/reference#1295) - patterns: include yet unstable exclusive range patterns (rust-lang/reference#1484) ## rust-lang/rust-by-example 7 commits in 229ad13b64d919b12e548d560f06d88963b25cd3..20482893d1a502df72f76762c97aed88854cdf81 2024-05-20 14:36:21 UTC to 2024-05-14 16:17:03 UTC - Clarify interchangability for From and Into (rust-lang/rust-by-example#1851) - Update ja.po based on the latest master (rust-lang/rust-by-example#1850) - Add explicit section link (rust-lang/rust-by-example#1847) - Adjust translation build on CI (rust-lang/rust-by-example#1849) - Update mdbook version in CI (rust-lang/rust-by-example#1848) - Fix some broken links in ja.po (rust-lang/rust-by-example#1844) - Fix an external link to absolute (rust-lang/rust-by-example#1842) ## rust-lang/rustc-dev-guide 8 commits in 2d1947ff34d50ca46dfe242ad75531a4c429bb52..b6d4a4940bab85cc91eec70cc2e3096dd48da62d 2024-05-17 17:04:58 UTC to 2024-05-09 13:22:03 UTC - Add a high level explanation of early/late bound params (rust-lang/rustc-dev-guide#1982) - Fix broken link to "Lowering" (rust-lang/rustc-dev-guide#1981) - Broken link fix (rust-lang/rustc-dev-guide#1980) - Add note about how to pick up abandoned PRs (rust-lang/rustc-dev-guide#1977) - Toc here is overkill (rust-lang/rustc-dev-guide#1976) - Link to lint `L-*` labels (rust-lang/rustc-dev-guide#1975) - Update the rustc_interface examples for current rustc (rust-lang/rustc-dev-guide#1974) - Edit `Parameter Environments`'s url as it has been edited in rust-lang#1953 (rust-lang/rustc-dev-guide#1973)
Update books ## rust-lang/book 8 commits in bebcf527e67755a989a1739b7cfaa8f0e6b30040..5e9051f71638aa941cd5dda465e25c61cde9594f 2024-05-16 14:58:56 UTC to 2024-05-07 23:58:22 UTC - Convert ch01-03-hello-cargo.md Listing 1-2 using `<Listing>` (rust-lang/book#3924) - infra: fix rendering bug in mdbook-trpl-note (rust-lang/book#3925) - infra: support `Listing`s without `file-name` (rust-lang/book#3920) - Add a `<Listing>` preprocessor (rust-lang/book#3918) - Update explanation according to code listing (rust-lang/book#3916) - infra: run package tests (rust-lang/book#3915) - Fix workspace behavior by excluding `listings` (rust-lang/book#3914) - Backport changes to chapter 8 (rust-lang/book#3913) ## rust-embedded/book 1 commits in 17842ebb050f62e40a4618edeb8e8ee86e758707..dd962bb82865a5284f2404e5234f1e3222b9c022 2024-05-17 23:43:59 UTC to 2024-05-17 23:43:59 UTC - 'llvm-tools-preview' component is now named 'llvm-tools' (rust-embedded/book#372) ## rust-lang/reference 2 commits in 51817951d0d213a0011f82b62aae02c3b3f2472e..e356977fceaa8591c762312d8d446769166d4b3e 2024-05-10 12:49:15 UTC to 2024-05-07 13:32:57 UTC - Document inline const/const block expression (rust-lang/reference#1295) - patterns: include yet unstable exclusive range patterns (rust-lang/reference#1484) ## rust-lang/rust-by-example 7 commits in 229ad13b64d919b12e548d560f06d88963b25cd3..20482893d1a502df72f76762c97aed88854cdf81 2024-05-20 14:36:21 UTC to 2024-05-14 16:17:03 UTC - Clarify interchangability for From and Into (rust-lang/rust-by-example#1851) - Update ja.po based on the latest master (rust-lang/rust-by-example#1850) - Add explicit section link (rust-lang/rust-by-example#1847) - Adjust translation build on CI (rust-lang/rust-by-example#1849) - Update mdbook version in CI (rust-lang/rust-by-example#1848) - Fix some broken links in ja.po (rust-lang/rust-by-example#1844) - Fix an external link to absolute (rust-lang/rust-by-example#1842) ## rust-lang/rustc-dev-guide 8 commits in 2d1947ff34d50ca46dfe242ad75531a4c429bb52..b6d4a4940bab85cc91eec70cc2e3096dd48da62d 2024-05-17 17:04:58 UTC to 2024-05-09 13:22:03 UTC - Add a high level explanation of early/late bound params (rust-lang/rustc-dev-guide#1982) - Fix broken link to "Lowering" (rust-lang/rustc-dev-guide#1981) - Broken link fix (rust-lang/rustc-dev-guide#1980) - Add note about how to pick up abandoned PRs (rust-lang/rustc-dev-guide#1977) - Toc here is overkill (rust-lang/rustc-dev-guide#1976) - Link to lint `L-*` labels (rust-lang/rustc-dev-guide#1975) - Update the rustc_interface examples for current rustc (rust-lang/rustc-dev-guide#1974) - Edit `Parameter Environments`'s url as it has been edited in rust-lang#1953 (rust-lang/rustc-dev-guide#1973)
Rollup merge of rust-lang#125332 - rustbot:docs-update, r=ehuss Update books ## rust-lang/book 8 commits in bebcf527e67755a989a1739b7cfaa8f0e6b30040..5e9051f71638aa941cd5dda465e25c61cde9594f 2024-05-16 14:58:56 UTC to 2024-05-07 23:58:22 UTC - Convert ch01-03-hello-cargo.md Listing 1-2 using `<Listing>` (rust-lang/book#3924) - infra: fix rendering bug in mdbook-trpl-note (rust-lang/book#3925) - infra: support `Listing`s without `file-name` (rust-lang/book#3920) - Add a `<Listing>` preprocessor (rust-lang/book#3918) - Update explanation according to code listing (rust-lang/book#3916) - infra: run package tests (rust-lang/book#3915) - Fix workspace behavior by excluding `listings` (rust-lang/book#3914) - Backport changes to chapter 8 (rust-lang/book#3913) ## rust-embedded/book 1 commits in 17842ebb050f62e40a4618edeb8e8ee86e758707..dd962bb82865a5284f2404e5234f1e3222b9c022 2024-05-17 23:43:59 UTC to 2024-05-17 23:43:59 UTC - 'llvm-tools-preview' component is now named 'llvm-tools' (rust-embedded/book#372) ## rust-lang/reference 2 commits in 51817951d0d213a0011f82b62aae02c3b3f2472e..e356977fceaa8591c762312d8d446769166d4b3e 2024-05-10 12:49:15 UTC to 2024-05-07 13:32:57 UTC - Document inline const/const block expression (rust-lang/reference#1295) - patterns: include yet unstable exclusive range patterns (rust-lang/reference#1484) ## rust-lang/rust-by-example 7 commits in 229ad13b64d919b12e548d560f06d88963b25cd3..20482893d1a502df72f76762c97aed88854cdf81 2024-05-20 14:36:21 UTC to 2024-05-14 16:17:03 UTC - Clarify interchangability for From and Into (rust-lang/rust-by-example#1851) - Update ja.po based on the latest master (rust-lang/rust-by-example#1850) - Add explicit section link (rust-lang/rust-by-example#1847) - Adjust translation build on CI (rust-lang/rust-by-example#1849) - Update mdbook version in CI (rust-lang/rust-by-example#1848) - Fix some broken links in ja.po (rust-lang/rust-by-example#1844) - Fix an external link to absolute (rust-lang/rust-by-example#1842) ## rust-lang/rustc-dev-guide 8 commits in 2d1947ff34d50ca46dfe242ad75531a4c429bb52..b6d4a4940bab85cc91eec70cc2e3096dd48da62d 2024-05-17 17:04:58 UTC to 2024-05-09 13:22:03 UTC - Add a high level explanation of early/late bound params (rust-lang/rustc-dev-guide#1982) - Fix broken link to "Lowering" (rust-lang/rustc-dev-guide#1981) - Broken link fix (rust-lang/rustc-dev-guide#1980) - Add note about how to pick up abandoned PRs (rust-lang/rustc-dev-guide#1977) - Toc here is overkill (rust-lang/rustc-dev-guide#1976) - Link to lint `L-*` labels (rust-lang/rustc-dev-guide#1975) - Update the rustc_interface examples for current rustc (rust-lang/rustc-dev-guide#1974) - Edit `Parameter Environments`'s url as it has been edited in rust-lang#1953 (rust-lang/rustc-dev-guide#1973)
Stabilisation PR rust-lang/rust#104087