update const stability docs #2098
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
|
@rust-lang/libs @rust-lang/libs-api FYI, and also would be good to get some feedback if you think this system makes sense or you would like to see some aspect of it work differently. :) |
RalfJung
force-pushed
the
const-stability
branch
from
659c467
to
e3a19bb
Compare
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 25, 2024
…try> Const stability checks v2 The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage: - It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention. - The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check. Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them: 1. const-stable functions 2. private/unstable functions that are meant to be callable from const-stable functions 3. functions that can make use of unstable const features Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories. This PR implements the following system: - `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions. - `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category. - `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls. Also, all the holes mentioned above have been closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to be manually marked `#[rustc_const_stable_indirect]` to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine. The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability. Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required. Also see the updated dev-guide at rust-lang/rustc-dev-guide#2098. I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`. ### Open question There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]` functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]` will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics. I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics. Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api` Part of rust-lang#129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown) Fixes rust-lang#131073 by making it so that const-stable functions are always stable try-job: test-various
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 25, 2024
…ompiler-errors Const stability checks v2 The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage: - It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention. - The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check. Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them: 1. const-stable functions 2. private/unstable functions that are meant to be callable from const-stable functions 3. functions that can make use of unstable const features Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories. This PR implements the following system: - `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions. - `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category. - `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls. Also, all the holes mentioned above have been closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to be manually marked `#[rustc_const_stable_indirect]` to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine. The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability. Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required. Also see the updated dev-guide at rust-lang/rustc-dev-guide#2098. I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`. ### Open question There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]` functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]` will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics. I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics. Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api` Part of rust-lang#129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown) Fixes rust-lang#131073 by making it so that const-stable functions are always stable try-job: test-various
|
rust-lang/rust#131349 is merged now, so could someone merge this docs PR as well? :) |
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Oct 31, 2024
…rrors Const stability checks v2 The const stability system has served us well ever since `const fn` were first stabilized. It's main feature is that it enforces *recursive* validity -- a stable const fn cannot internally make use of unstable const features without an explicit marker in the form of `#[rustc_allow_const_fn_unstable]`. This is done to make sure that we don't accidentally expose unstable const features on stable in a way that would be hard to take back. As part of this, it is enforced that a `#[rustc_const_stable]` can only call `#[rustc_const_stable]` functions. However, some problems have been coming up with increased usage: - It is baffling that we have to mark private or even unstable functions as `#[rustc_const_stable]` when they are used as helpers in regular stable `const fn`, and often people will rather add `#[rustc_allow_const_fn_unstable]` instead which was not our intention. - The system has several gaping holes: a private `const fn` without stability attributes whose inherited stability (walking up parent modules) is `#[stable]` is allowed to call *arbitrary* unstable const operations, but can itself be called from stable `const fn`. Similarly, `#[allow_internal_unstable]` on a macro completely bypasses the recursive nature of the check. Fundamentally, the problem is that we have *three* disjoint categories of functions, and not enough attributes to distinguish them: 1. const-stable functions 2. private/unstable functions that are meant to be callable from const-stable functions 3. functions that can make use of unstable const features Functions in the first two categories cannot use unstable const features and they can only call functions from the first two categories. This PR implements the following system: - `#[rustc_const_stable]` puts functions in the first category. It may only be applied to `#[stable]` functions. - `#[rustc_const_unstable]` by default puts functions in the third category. The new attribute `#[rustc_const_stable_indirect]` can be added to such a function to move it into the second category. - `const fn` without a const stability marker are in the second category if they are still unstable. They automatically inherit the feature gate for regular calls, it can now also be used for const-calls. Also, all the holes mentioned above have been closed. There's still one potential hole that is hard to avoid, which is when MIR building automatically inserts calls to a particular function in stable functions -- which happens in the panic machinery. Those need to be manually marked `#[rustc_const_stable_indirect]` to be sure they follow recursive const stability. But that's a fairly rare and special case so IMO it's fine. The net effect of this is that a `#[unstable]` or unmarked function can be constified simply by marking it as `const fn`, and it will then be const-callable from stable `const fn` and subject to recursive const stability requirements. If it is publicly reachable (which implies it cannot be unmarked), it will be const-unstable under the same feature gate. Only if the function ever becomes `#[stable]` does it need a `#[rustc_const_unstable]` or `#[rustc_const_stable]` marker to decide if this should also imply const-stability. Adding `#[rustc_const_unstable]` is only needed for (a) functions that need to use unstable const lang features (including intrinsics), or (b) `#[stable]` functions that are not yet intended to be const-stable. Adding `#[rustc_const_stable]` is only needed for functions that are actually meant to be directly callable from stable const code. `#[rustc_const_stable_indirect]` is used to mark intrinsics as const-callable and for `#[rustc_const_unstable]` functions that are actually called from other, exposed-on-stable `const fn`. No other attributes are required. Also see the updated dev-guide at rust-lang/rustc-dev-guide#2098. I think in the future we may want to tweak this further, so that in the hopefully common case where a public function's const-stability just exactly mirrors its regular stability, we never have to add any attribute. But right now, once the function is stable this requires `#[rustc_const_stable]`. ### Open question There is one point I could see we might want to do differently, and that is putting `#[rustc_const_unstable]` functions (but not intrinsics) in category 2 by default, and requiring an extra attribute for `#[rustc_const_not_exposed_on_stable]` or so. This would require a bunch of extra annotations, but would have the advantage that turning a `#[rustc_const_unstable]` into `#[rustc_const_stable]` will never change the way the function is const-checked. Currently, we often discover in the const stabilization PR that a function needs some other unstable const things, and then we rush to quickly deal with that. In this alternative universe, we'd work towards getting rid of the `rustc_const_not_exposed_on_stable` before stabilization, and once that is done stabilization becomes a trivial matter. `#[rustc_const_stable_indirect]` would then only be used for intrinsics. I think I like this idea, but might want to do it in a follow-up PR, as it will need a whole bunch of annotations in the standard library. Also, we probably want to convert all const intrinsics to the "new" form (`#[rustc_intrinsic]` instead of an `extern` block) before doing this to avoid having to deal with two different ways of declaring intrinsics. Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api` Part of rust-lang/rust#129815 (but not finished since this is not yet sufficient to safely let us expose `const fn` from hashbrown) Fixes rust-lang/rust#131073 by making it so that const-stable functions are always stable try-job: test-various
|
Seems like this was merged with a rebase, not a clean merge? That makes it a lot harder to automatically track which of my branches have been merged already... :( |
|
I think I just clicked one of the merge buttons, I'll talk with other dev-guide maintainers and see we can stick with one of the merging options, lol. |
@RalfJung actually just to clarify, would a rebase and merge work? I may have accidentally clicked the squash and merge button. |
|
Rebase and merge still means the commit as it exists in my branch does not end up in the repo, leaving me with no way to automatically determine that my branch was merged. So I have to delete all the old branches by hand, which is somewhat tedious. Lucky enough most rust-lang repos use a normal merge so I can have some scripts that detect all branches which have been merged (local and remote) and delete them. :) I understand some people prefer a linear history, but I don't quite understand why... and in rust-lang we don't seem to have a default policy either way. |
|
Right. So apparently in this repo the default "merge" button is disabled for some reason, I'll ask around why... This is just docs so I really don't think the rust-lang/rust no merge policy is relevant (and that's no merge master into PR, not the other way around). |
|
rust-lang/rust uses merge commits without rebase to merge PRs. That's the repo that I originally developed my auto-branch-deletion tooling for. :) The policy there is only about no merge commits inside a PR. |
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Nov 4, 2024
Update books ## rust-lang/edition-guide 3 commits in 1f07c242f8162a711a5ac5a4ea8fa7ec884ee7a9..2d482e203eb6d6e353814cf1415c5f94e590b9e0 2024-11-04 14:42:36 UTC to 2019-06-14 21:27:05 UTC - 2024: rustfmt style edition (rust-lang/edition-guide#331) - rustdoc: Fix doctest `include` paths (rust-lang/edition-guide#329) - docs(cargo): Cover MSRV-aware resolver (rust-lang/edition-guide#328) ## rust-lang/reference 3 commits in 23ce619966541bf2c80d45fdfeecf3393e360a13..da0f6dad767670da0e8cd5af8a7090db3272f626 2024-11-01 12:52:51 UTC to 2024-10-30 13:30:17 UTC - fix typo referring to 'Unsize' trait (rust-lang/reference#1669) - Add identifier syntax to items.md and subchapters (rust-lang/reference#1599) - Rename "object safe" to "dyn compatible" (rust-lang/reference#1666) ## rust-lang/rust-by-example 5 commits in 8bede1b919a81ab7d0c961f6bbf68d3efa297bd2..9db78608b17d5f4a6c033b8a3038466b87d63206 2024-10-31 21:03:20 UTC to 2024-10-26 16:06:05 UTC - fix(doc): correct small errors in pipes.md (rust-lang/rust-by-example#1894) - Fix ambiguous comment on 2.3 Arrays and Slices page (rust-lang/rust-by-example#1885) - Fix typo in generics/new_types (rust-lang/rust-by-example#1892) - docs(zh): fix known issues (rust-lang/rust-by-example#1891) - `read_lines`: Use `.map_while(Result::ok)` instead of `.flatten()`. (rust-lang/rust-by-example#1890) ## rust-lang/rustc-dev-guide 22 commits in 59d94ea75a0b157e148af14c73c2dd60efb7b60a..6a5accdaf10255882b1e6c59dfe5f1c79ac95484 2024-11-04 14:40:57 UTC to 2024-10-24 20:33:08 UTC - Add a link for the `reference` compiletest header (rust-lang/rustc-dev-guide#2096) - Slightly fix up the glossary (rust-lang/rustc-dev-guide#2127) - Remove an mdbook workaround (rust-lang/rustc-dev-guide#2124) - Fix broken links (rust-lang/rustc-dev-guide#2123) - Fix minicore.rs link (rust-lang/rustc-dev-guide#2122) - Update for recent dataflow simplifications. (rust-lang/rustc-dev-guide#2121) - Describe `minicore` test auxiliary and directive (rust-lang/rustc-dev-guide#2097) - Fix and update docs for `needs-force-clang-based-tests` (rust-lang/rustc-dev-guide#2085) - Add redirects for integration-testing and headers (rust-lang/rustc-dev-guide#2092) - Fix borked links (rust-lang/rustc-dev-guide#2119) - Describe how to revert a PR (rust-lang/rustc-dev-guide#2118) - Linkify the footnotes in the async closure chapter (rust-lang/rustc-dev-guide#2117) - Try to fix footnotes (rust-lang/rustc-dev-guide#2115) - Fix rustc-related links that are 404 right now (rust-lang/rustc-dev-guide#2112) - Async closures chapter (rust-lang/rustc-dev-guide#2110) - update rfl ci job policy (rust-lang/rustc-dev-guide#2108) - Fix internal and incomplete links (rust-lang/rustc-dev-guide#2107) - Describe why and how to use a separate build directory for rust-analyzer (rust-lang/rustc-dev-guide#2106) - Update current status of diagnostics translation infra (rust-lang/rustc-dev-guide#2105) - update const stability docs (rust-lang/rustc-dev-guide#2098) - Advice on auto-formatting C++ code (rust-lang/rustc-dev-guide#2104) - Update compiler-src.md (rust-lang/rustc-dev-guide#2102)
workingjubilee
added a commit
to workingjubilee/rustc
that referenced
this pull request
Nov 5, 2024
Update books ## rust-lang/edition-guide 3 commits in 1f07c242f8162a711a5ac5a4ea8fa7ec884ee7a9..2d482e203eb6d6e353814cf1415c5f94e590b9e0 2024-11-04 14:42:36 UTC to 2019-06-14 21:27:05 UTC - 2024: rustfmt style edition (rust-lang/edition-guide#331) - rustdoc: Fix doctest `include` paths (rust-lang/edition-guide#329) - docs(cargo): Cover MSRV-aware resolver (rust-lang/edition-guide#328) ## rust-lang/reference 3 commits in 23ce619966541bf2c80d45fdfeecf3393e360a13..da0f6dad767670da0e8cd5af8a7090db3272f626 2024-11-01 12:52:51 UTC to 2024-10-30 13:30:17 UTC - fix typo referring to 'Unsize' trait (rust-lang/reference#1669) - Add identifier syntax to items.md and subchapters (rust-lang/reference#1599) - Rename "object safe" to "dyn compatible" (rust-lang/reference#1666) ## rust-lang/rust-by-example 5 commits in 8bede1b919a81ab7d0c961f6bbf68d3efa297bd2..9db78608b17d5f4a6c033b8a3038466b87d63206 2024-10-31 21:03:20 UTC to 2024-10-26 16:06:05 UTC - fix(doc): correct small errors in pipes.md (rust-lang/rust-by-example#1894) - Fix ambiguous comment on 2.3 Arrays and Slices page (rust-lang/rust-by-example#1885) - Fix typo in generics/new_types (rust-lang/rust-by-example#1892) - docs(zh): fix known issues (rust-lang/rust-by-example#1891) - `read_lines`: Use `.map_while(Result::ok)` instead of `.flatten()`. (rust-lang/rust-by-example#1890) ## rust-lang/rustc-dev-guide 22 commits in 59d94ea75a0b157e148af14c73c2dd60efb7b60a..6a5accdaf10255882b1e6c59dfe5f1c79ac95484 2024-11-04 14:40:57 UTC to 2024-10-24 20:33:08 UTC - Add a link for the `reference` compiletest header (rust-lang/rustc-dev-guide#2096) - Slightly fix up the glossary (rust-lang/rustc-dev-guide#2127) - Remove an mdbook workaround (rust-lang/rustc-dev-guide#2124) - Fix broken links (rust-lang/rustc-dev-guide#2123) - Fix minicore.rs link (rust-lang/rustc-dev-guide#2122) - Update for recent dataflow simplifications. (rust-lang/rustc-dev-guide#2121) - Describe `minicore` test auxiliary and directive (rust-lang/rustc-dev-guide#2097) - Fix and update docs for `needs-force-clang-based-tests` (rust-lang/rustc-dev-guide#2085) - Add redirects for integration-testing and headers (rust-lang/rustc-dev-guide#2092) - Fix borked links (rust-lang/rustc-dev-guide#2119) - Describe how to revert a PR (rust-lang/rustc-dev-guide#2118) - Linkify the footnotes in the async closure chapter (rust-lang/rustc-dev-guide#2117) - Try to fix footnotes (rust-lang/rustc-dev-guide#2115) - Fix rustc-related links that are 404 right now (rust-lang/rustc-dev-guide#2112) - Async closures chapter (rust-lang/rustc-dev-guide#2110) - update rfl ci job policy (rust-lang/rustc-dev-guide#2108) - Fix internal and incomplete links (rust-lang/rustc-dev-guide#2107) - Describe why and how to use a separate build directory for rust-analyzer (rust-lang/rustc-dev-guide#2106) - Update current status of diagnostics translation infra (rust-lang/rustc-dev-guide#2105) - update const stability docs (rust-lang/rustc-dev-guide#2098) - Advice on auto-formatting C++ code (rust-lang/rustc-dev-guide#2104) - Update compiler-src.md (rust-lang/rustc-dev-guide#2102)
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 5, 2024
Rollup merge of rust-lang#132601 - rustbot:docs-update, r=ehuss Update books ## rust-lang/edition-guide 3 commits in 1f07c242f8162a711a5ac5a4ea8fa7ec884ee7a9..2d482e203eb6d6e353814cf1415c5f94e590b9e0 2024-11-04 14:42:36 UTC to 2019-06-14 21:27:05 UTC - 2024: rustfmt style edition (rust-lang/edition-guide#331) - rustdoc: Fix doctest `include` paths (rust-lang/edition-guide#329) - docs(cargo): Cover MSRV-aware resolver (rust-lang/edition-guide#328) ## rust-lang/reference 3 commits in 23ce619966541bf2c80d45fdfeecf3393e360a13..da0f6dad767670da0e8cd5af8a7090db3272f626 2024-11-01 12:52:51 UTC to 2024-10-30 13:30:17 UTC - fix typo referring to 'Unsize' trait (rust-lang/reference#1669) - Add identifier syntax to items.md and subchapters (rust-lang/reference#1599) - Rename "object safe" to "dyn compatible" (rust-lang/reference#1666) ## rust-lang/rust-by-example 5 commits in 8bede1b919a81ab7d0c961f6bbf68d3efa297bd2..9db78608b17d5f4a6c033b8a3038466b87d63206 2024-10-31 21:03:20 UTC to 2024-10-26 16:06:05 UTC - fix(doc): correct small errors in pipes.md (rust-lang/rust-by-example#1894) - Fix ambiguous comment on 2.3 Arrays and Slices page (rust-lang/rust-by-example#1885) - Fix typo in generics/new_types (rust-lang/rust-by-example#1892) - docs(zh): fix known issues (rust-lang/rust-by-example#1891) - `read_lines`: Use `.map_while(Result::ok)` instead of `.flatten()`. (rust-lang/rust-by-example#1890) ## rust-lang/rustc-dev-guide 22 commits in 59d94ea75a0b157e148af14c73c2dd60efb7b60a..6a5accdaf10255882b1e6c59dfe5f1c79ac95484 2024-11-04 14:40:57 UTC to 2024-10-24 20:33:08 UTC - Add a link for the `reference` compiletest header (rust-lang/rustc-dev-guide#2096) - Slightly fix up the glossary (rust-lang/rustc-dev-guide#2127) - Remove an mdbook workaround (rust-lang/rustc-dev-guide#2124) - Fix broken links (rust-lang/rustc-dev-guide#2123) - Fix minicore.rs link (rust-lang/rustc-dev-guide#2122) - Update for recent dataflow simplifications. (rust-lang/rustc-dev-guide#2121) - Describe `minicore` test auxiliary and directive (rust-lang/rustc-dev-guide#2097) - Fix and update docs for `needs-force-clang-based-tests` (rust-lang/rustc-dev-guide#2085) - Add redirects for integration-testing and headers (rust-lang/rustc-dev-guide#2092) - Fix borked links (rust-lang/rustc-dev-guide#2119) - Describe how to revert a PR (rust-lang/rustc-dev-guide#2118) - Linkify the footnotes in the async closure chapter (rust-lang/rustc-dev-guide#2117) - Try to fix footnotes (rust-lang/rustc-dev-guide#2115) - Fix rustc-related links that are 404 right now (rust-lang/rustc-dev-guide#2112) - Async closures chapter (rust-lang/rustc-dev-guide#2110) - update rfl ci job policy (rust-lang/rustc-dev-guide#2108) - Fix internal and incomplete links (rust-lang/rustc-dev-guide#2107) - Describe why and how to use a separate build directory for rust-analyzer (rust-lang/rustc-dev-guide#2106) - Update current status of diagnostics translation infra (rust-lang/rustc-dev-guide#2105) - update const stability docs (rust-lang/rustc-dev-guide#2098) - Advice on auto-formatting C++ code (rust-lang/rustc-dev-guide#2104) - Update compiler-src.md (rust-lang/rustc-dev-guide#2102)
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.
This updates the docs for rust-lang/rust#131349. Should only land once that PR landed.