Skip to content
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

Merged
merged 2 commits into from
May 10, 2024
Merged

Conversation

nbdd0121
Copy link
Contributor

@nbdd0121 nbdd0121 commented Nov 7, 2022

Stabilisation PR rust-lang/rust#104087

Havvy
Havvy previously requested changes Nov 7, 2022
Copy link
Contributor

@Havvy Havvy left a 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.

src/expressions/block-expr.md Outdated Show resolved Hide resolved
src/expressions/block-expr.md Outdated Show resolved Hide resolved
src/expressions/block-expr.md Outdated Show resolved Hide resolved
@ehuss ehuss added the S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository label Nov 9, 2022
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
Copy link
Contributor

@ehuss ehuss left a 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 the expr docs to mention that limitation? I understand this might change for the edition, but it doesn't look like that work has finished.

Comment on lines 143 to 152
fn main() {
const FOO: i32 = 1 + 1;
let x = foo(FOO);
}
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

src/expressions/block-expr.md Outdated Show resolved Hide resolved
@ehuss ehuss added S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author. and removed S-waiting-on-stabilization Waiting for a stabilization PR to be merged in the main Rust repository labels Apr 27, 2024
Copy link
Contributor

@ehuss ehuss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@RalfJung
Copy link
Member

Auto-merge is enabled but nothing is happening...?

@ehuss ehuss added this pull request to the merge queue May 10, 2024
@ehuss
Copy link
Contributor

ehuss commented May 10, 2024

Thanks, I didn't see that it was blocked.

Merged via the queue into rust-lang:master with commit e356977 May 10, 2024
1 check passed
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
Labels
S-waiting-on-author Status: The marked PR is awaiting some action (such as code changes) from the PR author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants