Remove #[cfg(not(test))] gates in core

2025-03-06T21:21:59+00:00

These gates are unnecessary now that unit tests for `core` are in a separate package, `coretests`, instead of in the same files as the source code. They previously prevented the two `core` versions from conflicting with each other.

docs: fix broken intra-doc links that never worked

2025-02-15T19:21:38+00:00

update version placeholders

2025-01-08T19:02:18+00:00

Use field init shorthand where possible

2024-12-17T22:33:10+00:00

Field init shorthand allows writing initializers like `tcx: tcx` as `tcx`. The compiler already uses it extensively. Fix the last few places where it isn't yet used.

Remove rustc_const_stable attribute on const NOOP

2024-12-09T23:08:30+00:00

This was accidentally reintroduced while editing #133089.

Stabilize noop_waker

2024-12-05T22:14:17+00:00

Co-authored-by: zachs18 <8355914+zachs18@users.noreply.github.com>

update cfgs

2024-11-27T15:14:54+00:00

get rid of a whole bunch of unnecessary rustc_const_unstable attributes

2024-11-02T08:59:55+00:00

Re-do recursive const stability checks

2024-10-25T18:31:40+00:00

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.

replace placeholder version

2024-10-16T03:13:55+00:00

(cherry picked from commit 567fd9610cbfd220844443487059335d7e1ff021)

rust/library/core/src/task, branch 1.87.0