rust/library/std/src/thread/local.rs, branch 1.84.1

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.

Fix std tests for wasm32-wasip2 target

2024-09-29T02:48:13+00:00

Replace `move||` with `move ||` in `compiler/` and `library/`

2024-06-18T15:25:08+00:00

Edit from #126631 to revert changes on ui tests

std: make TLS accessors closures that return pointers

2024-05-24T22:19:47+00:00

Change method calls to using the method directly

2024-04-08T21:48:07+00:00

This is in accordance with Clippy's redundant_closure_for_method_calls.

Add `SAFETY` comments to the thread local implementation

2024-04-08T21:47:09+00:00

Reduce `unsafe` block scope and add `SAFETY` comments.

Update thread local docs with idiomatic cell type use

2024-04-08T21:43:24+00:00

The `thread_local!` examples use `RefCell` for `Copy` types. Update examples to have one `Copy` and one non-`Copy` type using `Cell` and `RefCell`, respectively.

Get rid of some `#[allow(static_mut_refs)]`

2024-02-23T15:02:25+00:00

Add `rustc_confusables` annotations to some stdlib APIs

2024-02-22T18:04:55+00:00

Help with common API confusion, like asking for `push` when the data structure really has `append`. ``` error[E0599]: no method named `size` found for struct `Vec<{integer}>` in the current scope --> $DIR/rustc_confusables_std_cases.rs:17:7 | LL | x.size(); | ^^^^ | help: you might have meant to use `len` | LL | x.len(); | ~~~ help: there is a method with a similar name | LL | x.resize(); | ~~~~~~ ``` #59450

Improve wording of static_mut_ref

2024-02-18T03:01:40+00:00

Rename `static_mut_ref` lint to `static_mut_refs`.