https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.87.0 2025-03-07T04:20:38+00:00 2025-03-07T04:20:38+00:00 Thalia Archibald thalia@archibald.dev 2025-03-05T04:28:38+00:00 urn:sha1:988eb1997014987caad878699ee1e7c000214508 Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. These functions were added to all preludes in Rust 1.80. 2025-01-16T06:17:57+00:00 Scott McMurray scottmcm@users.noreply.github.com 2025-01-10T21:00:45+00:00 urn:sha1:c18718c9c28cc4c700312775c2b7f87cd79d3063 2024-11-27T15:14:54+00:00 Boxy rust@boxyuwu.dev 2024-11-27T15:14:47+00:00 urn:sha1:22998f078588cf479530ff93e4a66ab4bb666398 2024-10-25T18:31:40+00:00 Ralf Jung post@ralfj.de 2024-10-06T17:59:19+00:00 urn:sha1:a0215d8e46aab41219dea0bb1cbaaf97dafe2f89 Fundamentally, we have *three* disjoint categories of functions: 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 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, several holes in recursive const stability checking are being 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 *not* be `rustc_const_unstable` (or manually get a `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. 2024-09-26T13:42:37+00:00 Ralf Jung post@ralfj.de 2024-09-26T13:42:37+00:00 urn:sha1:ef87a7f663826b67cf47e147546ada7e1d081c46 2024-09-18T07:05:14+00:00 bors bors@rust-lang.org 2024-09-18T07:05:14+00:00 urn:sha1:f68c28b6cefb9e1f9c258f20a3b1b7b7cddbc84f Take more advantage of the `isize::MAX` limit in `Layout` Things like `padding_needed_for` are current implemented being super careful to handle things like `Layout::size` potentially being `usize::MAX`. But now that #95295 has happened, that's no longer a concern. It's possible to add two `Layout::size`s together without risking overflow now. So take advantage of that to remove a bunch of checked math that's not actually needed. For example, the round-up-and-add-next-size in `extend` doesn't need any overflow checks at all, just the final check for compatibility with the alignment. (And while I was doing that I made it all unstably const, because there's nothing in `Layout` that's fundamentally runtime-only.) 2024-09-18T03:05:57+00:00 Scott McMurray scottmcm@users.noreply.github.com 2024-09-01T08:31:07+00:00 urn:sha1:18ca8bf8ee77deb13967620b1f4829f22c16dae1 Things like `padding_needed_for` are current implemented being super careful to handle things like `Layout::size` potentially being `usize::MAX`. But now that 95295 has happened, that's no longer a concern. It's possible to add two `Layout::size`s together without risking overflow now. So take advantage of that to remove a bunch of checked math that's not actually needed. For example, the round-up-and-add-next-size in `extend` doesn't need any overflow checks at all, just the final check for compatibility with the alignment. (And while I was doing that I made it all unstably const, because there's nothing in `Layout` that's fundamentally runtime-only.) 2024-09-08T06:45:41+00:00 Ralf Jung post@ralfj.de 2024-09-08T06:45:41+00:00 urn:sha1:7f9a541059b1bf5322e94668792e933a48975917 2024-08-23T22:26:45+00:00 Ben Kimock kimockb@gmail.com 2024-08-23T22:26:45+00:00 urn:sha1:5d98d2052923c116a0493528d41d656e9b29c92f 2024-03-25T20:12:06+00:00 Daniel Paoliello danpao@microsoft.com 2024-03-25T18:02:02+00:00 urn:sha1:d261647c93380d5ed535c5ed2f176792f4d74d6c