rust/library/std/src/prelude/mod.rs, branch try

span: add a "future" edition

2025-02-24T14:35:30+00:00

It's hard to implement edition migrations without having a perma-unstable "future" edition to target.

Remove the common prelude module

2025-02-11T21:04:27+00:00

This fixes the issues described in https://github.com/rust-lang/rust/issues/136102. Primarily, this resolves some issues with how the documentation for the prelude is generated: - It avoids showing "unstable" for macros in the prelude that are actually stable. - Avoids duplication of some pages due to the previous lack of `doc(no_inline)`. - Makes the different edition preludes consistent, and sets a pattern that can be used by future editions. We may need to rearrange these modules in the future if we decide to remove anything from the prelude again. If we do, I think we should look into a different solution that avoids the documentation problems.

remove Rustc{En,De}codable from library and compiler

2025-01-14T15:16:38+00:00

make rustc_encodable_decodable feature properly unstable

2025-01-14T15:16:38+00:00

update version placeholders

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

Reword prelude for AsyncFn stabilization

2024-12-13T00:04:57+00:00

Stabilize the Rust 2024 prelude

2024-12-11T21:09:57+00:00

Avoid comments that describe multiple `use` items.

2024-07-16T22:02:46+00:00

There are some comments describing multiple subsequent `use` items. When the big `use` reformatting happens some of these `use` items will be reordered, possibly moving them away from the comment. With this additional level of formatting it's not really feasible to have comments of this type. This commit removes them in various ways: - merging separate `use` items when appropriate; - inserting blank lines between the comment and the first `use` item; - outright deletion (for comments that are relatively low-value); - adding a separate "top-level" comment. We also entirely skip formatting for four library files that contain nothing but `pub use` re-exports, where reordering would be painful.

Add `size_of`, `size_of_val`, `align_of`, and `align_of_val` to the prelude

2024-05-13T13:11:28+00:00

Many, many projects use `size_of` to get the size of a type. However, it's also often equally easy to hardcode a size (e.g. `8` instead of `size_of::()`). Minimizing friction in the use of `size_of` helps ensure that people use it and make code more self-documenting. The name `size_of` is unambiguous: the name alone, without any prefix or path, is self-explanatory and unmistakeable for any other functionality. Adding it to the prelude cannot produce any name conflicts, as any local definition will silently shadow the one from the prelude. Thus, we don't need to wait for a new edition prelude to add it. Add `size_of_val`, `align_of`, and `align_of_val` as well, with similar justification: widely useful, self-explanatory, unmistakeable for anything else, won't produce conflicts.

Remove RustcEncodable/Decodable from 2024 prelude

2024-03-22T20:30:48+00:00