Change:
implemented in libraries, with a special marker to tell the compiler it exists. The marker is the attribute `#[lang = "..."]` and there are various different values of `...`, i.e. various different 'lang <del> items'. </del> <ins> items'. Most of them can only be defined once. </ins> <del> For example, `Box` pointers require a lang item for allocation. A freestanding program that uses the `Box` sugar for dynamic allocations via `malloc` and `free`: </del> <ins> Lang items are loaded lazily by the compiler; e.g. if one never uses `Box` then there is no need to define a function for `exchange_malloc`. `rustc` will emit an error when an item is needed but not found in the current crate or any that it depends on. Some features provided by lang items: - overloadable operators via traits: the traits corresponding to the `==`, `<`, dereferencing (`*`) and `+` (etc.) operators are all marked with lang items; those specific four are `eq`, `partial_ord`, `deref`/`deref_mut`, and `add` respectively. - panicking: the `panic` and `panic_impl` lang items, among others. - stack unwinding: the lang item `eh_personality` is a function used by the failure mechanisms of the compiler. This is often mapped to GCC's personality function (see the [`std` implementation][personality] for more information), but programs which don't trigger a panic can be assured that this function is never called. Additionally, a `eh_catch_typeinfo` static is needed for certain targets which implement Rust panics on top of C++ exceptions. - the traits in `core::marker` used to indicate types of various kinds; e.g. lang items `sized`, `sync` and `copy`. - memory allocation, see below. Most lang items are defined by `core`, but if you're trying to build an executable without the `std` crate, you might run into the need for lang item definitions. [personality]: https://github.com/rust-lang/rust/blob/master/library/std/src/personality/gcc.rs ## Example: Implementing a `Box` `Box` pointers require two lang items: one for the type itself and one for allocation. A freestanding program that uses the `Box` sugar for dynamic allocations via `malloc` and `free`: </ins> ```rust,ignore (libc-is-finicky) <del> #![feature(lang_items, start, libc, core_intrinsics, rustc_private, rustc_attrs)] </del> <ins> #![feature(lang_items, start, core_intrinsics, rustc_private, panic_unwind, rustc_attrs)] </ins> #![allow(internal_features)] #![no_std] <ins> extern crate libc; extern crate unwind; use core::ffi::c_void; </ins> use core::intrinsics; use core::panic::PanicInfo; use core::ptr::NonNull; <del> extern crate libc; </del> <ins> pub struct Global; // the global allocator </ins> struct Unique<T>(NonNull<T>); #[lang = "owned_box"] <del> pub struct Box<T>(Unique<T>); </del> <ins> pub struct Box<T, A = Global>(Unique<T>, A); </ins> impl<T> Box<T> { pub fn new(x: T) -> Self {

Discussion:
or The examples don't compile and the list of items is outdated. Should the list at the bottom of the page still be updated? The amount of language items has grown and there's already a list . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim label: +A-lang-item
I think linking to the source code is better than trying to keep the list up to date, yes. We might still want to document the language items that are required for a binary, since those are "user facing" in a way the others aren't.
Ideally we could find a way to run rustdoc on the examples (as doctests) so they don't get outdated.
The guidance could be to the nomicon because there's already .