Document inline const/const block expression #1295
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Havvy
previously requested changes
Nov 7, 2022
ehuss
added
the
S-waiting-on-stabilization
GuillaumeGomez
added a commit
to GuillaumeGomez/rust
that referenced
this pull request
Apr 22, 2024
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 22, 2024
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 24, 2024
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 24, 2024
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 24, 2024
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 24, 2024
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 24, 2024
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
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this pull request
Apr 25, 2024
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
ehuss
reviewed
Apr 27, 2024
There was a problem hiding this comment.
@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
exprin a macro. If that is correct, can you update theexprdocs 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
Comment on lines
143
to
152
| fn main() { | ||
| const FOO: i32 = 1 + 1; | ||
| let x = foo(FOO); | ||
| } |
There was a problem hiding this comment.
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?
ehuss
added
S-waiting-on-author
11 tasks
|
Auto-merge is enabled but nothing is happening...? |
|
Thanks, I didn't see that it was blocked. |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
May 20, 2024
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)
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
May 20, 2024
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)
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
May 21, 2024
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)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stabilisation PR rust-lang/rust#104087